Android App Shell - Buttons and touch - Phase I

Færdiggjort Opslået Jan 4, 2012 Betalt ved levering
Færdiggjort Betalt ved levering

This will be Phase I of a 2- to 3-phase project for creating a basic Android app shell.

Phase I will consist of a small app shell that runs in the simulator with some limited functionality, including a splash screen, buttons for interactivity and touch screen responses that play [url removed, login to view] MP4 videos.

I am a professional software developer, so I have a solid perspective on the amount of efforts required to produce the results. You can also find me on the workers side for confirmation of legitimacy.

DeliverablesScreenshots, backgrounds, button images and videos will be provided to the winning bidder. Attached are sample screen shots.

REQUIRED KNOWLEDGE

- Java, Android SDK, touch-interactions, animations, transitions and video playback.

FULL APP DETAILS

It is important that the app is designed (& coded) in such a way that it is modular and logical, such that updates, additions, etc. can be easily managed. As such, an overall picture follows:

The app will have a welcome screen with (essentially) a play button, other apps button, and buy-now button. These buttons should be self explanatory.

The app, itself, will be a touch-based interactive app that plays videos, with limitations on certain functionality dependent upon whether the app has been purchased. THIS IS AN ASSUMPTION THAT ANDROID APPS HAVE A BUY-LATER OPTION. If this assumption is incorrect, please inform.

----------------

PHASE I - This Project

NOTE: The screens, buttons, text, etc. described below will be dummy images/text. They do not need to be aligned/formatted perfectly. The functionality is the important aspect.

Functionality

1. Splash screen displayed while the app is loading.

2. Welcome screen to start the app with three buttons as described above.

3. Other Apps button will open a sliding up or down, near-full-screen window with a list of other apps. Clicking these other app buttons will take them to a website (any for now). There will be a button on this window to close it (slide up/down) to return to the welcome screen. This screen must be completely modular and reusable from anywhere within the app.

4. Buy-Now button will open a sliding up/down, near-full-screen window with a graphic, some text, and two buttons: One to go to the android store (if applicable) and one to close the window. This screen must be completely modular and reusable from anywhere within the app.

5. The Play button will transition to the main app window. ENSURE ALL CLEANUP IS DONE upon the end of the transition. Memory leaks and excessive memory usage are unacceptable.

6. The main app window will consist of a background image. It will have two + two buttons and touch response. The functionality is as follows:

6a. Button 1 will present a slide-up menu with two buttons. One will open an About window (with an image, some text, and a button to close). The other button will play video 1. Depressing Button 1 (not in the slide-up menu) again will close the slide-up menu (animated).

6b. Button 2 will return the user to the welcome screen.

6c. There will be two designated areas in the background image that will respond to touches. One area will play video 2. The other area will display the Buy Now window (as described earlier).

DELIVERY

This Phase I app will be delivered with full source that can be compiled and run on a Mac running OS X Lion using the latest Android SDK & development tools. In your delivery, please include a BRIEF document on the tools + install + compile and run info.

Q&A - Some questions that have been asked and some answers

1. It should support any device capable of playing [url removed, login to view] MP4 videos ranging from 320x480 to 640x960 to 768x1024 (iPhone/iPad dimensions). Use the minimum common denominator. If technology is too old, then it's not included (e.g. iPhone 3G does not work with our existing apps). This also means that the app needs to detect the type of device to determine which video (& graphics) to use.

2. According to Wiki, 3.2 (Honeycomb) "added" optimization for a broader range of screen sizes. We need the one that will work on all modern/supporting devices. E.g. We build iPhone apps in iOS 5.x, but target 4.1, because that is the oldest iOS version that supports the technology. Same concept for an android app, if applicable.

3. We use openGL (cocos2d to be exact) for drawing on the screens, from background images, button images, animations, etc. So, whatever is necessary to accomplish all of those in an android app, we need the framework for it.

1. It should support any device capable of playing [url removed, login to view] MP4 videos ranging from 320x480 to 640x960 to 768x1024 (iPhone/iPad dimensions). Use the minimum common denominator. If technology is too old, then it's not included (e.g. iPhone 3G does not work with our existing apps).

2. According to Wiki, 3.2 (Honeycomb) "added" optimization for a broader range of screen sizes. We need the one that will work on all modern/supporting devices. E.g. I build my iPhone apps in iOS 5.x, but I target 4.1, because that is the oldest iOS version that supports the technology. Can the same be applied to building an android app? Is that not part of the target architecture, not the code?

3. It could be that I just don't understand Android apps (& devices) well enough. I don't want a popup window that displays the option to buy to REQUIRE hitting a hardware back button to go back to the main screen, as I might lose out on important callbacks (not sure how that works).

4. I use openGL (cocos2d to be exact) for drawing on the screens, from background images, button images, animations, etc. So, whatever is necessary to accomplish all of those, I need that framework.

1. It should support any device capable of playing [url removed, login to view] MP4 videos ranging from 320x480 to 640x960 to 768x1024 (iPhone/iPad dimensions). Use the minimum common denominator. If technology is too old, then it's not included (e.g. iPhone 3G does not work with our existing apps).

2. According to Wiki, 3.2 (Honeycomb) "added" optimization for a broader range of screen sizes. We need the one that will work on all modern/supporting devices. E.g. I build my iPhone apps in iOS 5.x, but I target 4.1, because that is the oldest iOS version that supports the technology. Can the same be applied to building an android app? Is that not part of the target architecture, not the code?

3. It could be that I just don't understand Android apps (& devices) well enough. I don't want a popup window that displays the option to buy to REQUIRE hitting a hardware back button to go back to the main screen, as I might lose out on important callbacks (not sure how that works).

4. I use openGL (cocos2d to be exact) for drawing on the screens, from background images, button images, animations, etc. So, whatever is necessary to accomplish all of those, I need that framework.

1. It should support any device capable of playing [url removed, login to view] MP4 videos ranging from 320x480 to 640x960 to 768x1024 (iPhone/iPad dimensions). Use the minimum common denominator. If technology is too old, then it's not included (e.g. iPhone 3G does not work with our existing apps).

2. According to Wiki, 3.2 (Honeycomb) "added" optimization for a broader range of screen sizes. We need the one that will work on all modern/supporting devices. E.g. I build my iPhone apps in iOS 5.x, but I target 4.1, because that is the oldest iOS version that supports the technology. Can the same be applied to building an android app? Is that not part of the target architecture, not the code?

3. It could be that I just don't understand Android apps (& devices) well enough. I don't want a popup window that displays the option to buy to REQUIRE hitting a hardware back button to go back to the main screen, as I might lose out on important callbacks (not sure how that works).

4. I use openGL (cocos2d to be exact) for drawing on the screens, from background images, button images, animations, etc. So, whatever is necessary to accomplish all of those, I need that framework.

1. It should support any device capable of playing [url removed, login to view] MP4 videos ranging from 320x480 to 640x960 to 768x1024 (iPhone/iPad dimensions). Use the minimum common denominator. If technology is too old, then it's not included (e.g. iPhone 3G does not work with our existing apps).

2. According to Wiki, 3.2 (Honeycomb) "added" optimization for a broader range of screen sizes. We need the one that will work on all modern/supporting devices. E.g. I build my iPhone apps in iOS 5.x, but I target 4.1, because that is the oldest iOS version that supports the technology. Can the same be applied to building an android app? Is that not part of the target architecture, not the code?

3. It could be that I just don't understand Android apps (& devices) well enough. I don't want a popup window that displays the option to buy to REQUIRE hitting a hardware back button to go back to the main screen, as I might lose out on important callbacks (not sure how that works).

4. I use openGL (cocos2d to be exact) for drawing on the screens, from background images, button images, animations, etc. So, whatever is necessary to accomplish all of those, I need that framework.

1. It should support any device capable of playing [url removed, login to view] MP4 videos ranging from 320x480 to 640x960 to 768x1024 (iPhone/iPad dimensions). Use the minimum common denominator. If technology is too old, then it's not included (e.g. iPhone 3G does not work with our existing apps).

2. According to Wiki, 3.2 (Honeycomb) "added" optimization for a broader range of screen sizes. We need the one that will work on all modern/supporting devices. E.g. I build my iPhone apps in iOS 5.x, but I target 4.1, because that is the oldest iOS version that supports the technology. Can the same be applied to building an android app? Is that not part of the target architecture, not the code?

3. It could be that I just don't understand Android apps (& devices) well enough. I don't want a popup window that displays the option to buy to REQUIRE hitting a hardware back button to go back to the main screen, as I might lose out on important callbacks (not sure how that works).

4. I use openGL (cocos2d to be exact) for drawing on the screens, from background images, button images, animations, etc. So, whatever is necessary to accomplish all of those, I need that framework.

This broadcast message was sent to all bidders on Friday Jan 6, 2012 3:58:47 PM:

I have added an attachment to the project. It includes a README and screenshots for this phase of the project.

Android Ingeniørarbejde Java Mobile App Development Projekt Ledelse Software Arkitektur Software Testning

Projekt ID: #2697564

Om projektet

3 bud Remote projekt Aktiv Jan 8, 2012

Tildelt til:

asfdfdfd

See private message.

$150.45 USD in 7 dage
(41 bedømmelser)
5.5

3 freelancere byder i gennemsnit $185 timen for dette job

MVStudio

See private message.

$204 USD in 7 dage
(8 bedømmelser)
5.6
hppy

See private message.

$200.6 USD in 7 dage
(0 bedømmelser)
0.0