FAST iPhone to Android app conversion
$5000-15000 USD
Pagato alla consegna
Is your team the fastest? Are you the best? Can they convert a fully featured iPhone app into a Droid equivalent in record time while maintaining high quality?
*Then we want **you!***
Following the successful release of our iPhone app "Playgrounds!" we need to immediately deliver an Android version by early August. We can provide the full code-base in Cocoa/Objective-C, the art assets, and all the server side APIs you'll need to create a fully functional Android equivalent.
If this sounds like a challenge your company is up to, then bid now! We'll be focusing on companies with proven delivery times and proven high quality products. Bidders should be prepared to show apps they've developed on both platforms.
The successful bidder will be prepared to handle the following key technologies we used for the iPhone app, or provide equivalent functionality:
* CoreData
* CoreLocation
* CoreGraphics
* Facebook Connect
* JSON Parsing
* Reverse and Forward Geocoding
* MapKit/Google Maps integration
* AddThis (for application sharing)
We will provide documentation, the existing iPhone code, and our original art assets. We will expect regular updates and builds to test, but in general will expect the company to operate very independently throughout the lifecycle of this project.
Visit the following link and download our free app for iPhone ***before*** you bid!
[url removed, login to view]
We expect bidders to have a basic comprehension of our existing app before making any bid. Bidders who include a short note in their bids that contains a reference to a piece of content within the app will be given priority.
Remember, we're not interested in the lowest bid as much as those who can prove that they can complete this project within the 30-day deadline!
## Deliverables
**Core Requirements:**
* Contractor must draft a requirements document themselves based on this document, the iPhone app source code, and the design files (containing screen layouts) attached to this project
* Contractor must make a 1:1 conversion of iPhone functionality to Android (working on version 2.1+)
* 1:1 equivalence is considered to be functional equivalence, not code equivalence, as implementation details may need to change. This also allows for differences in the UI and graphics, where the contractor should provide placeholder graphics where appropriate if the existing art asset library from the iPhone app is inadequate
* Contractor must notify KaBOOM! of any and all 3rd party libraries, code, or resources they wish to integrate into the project and obtain approval for them before the deadline. This does not apply to Android versions of iPhone libraries (such as Facebook Connect) we're already using in the iPhone codebase
* Contractor will sign Non-disclosure agreement
* Contractor must supply weekly deliverables that can be tested by KaBOOM! in addition to the vWorker required status reports
* Contractor must deliver all code created for the project along with the final deliverable
* Contractor does not retain any copyrights once the final deliverable is delivered: contractor transfers all rights to the developed application along with its code to KaBOOM!
* Contractor will not receive credit for the development of the application and may not feature the application in their work portfolio
* Final deliverable should not contain any crash bugs, missing functionality (unless approved by KaBOOM!), or broken functionality - nevertheless, it is understood that minor bugs may exist in the final deliverable, and as long as they do not impede the user from interacting with core functionality as they expect they should be able to, these minor bugs will not result in a failed deliverable
* Final deliverable must work across normal and large Androids displays, as defined in the Android developer documentation ([url removed, login to view]), and not use absolute layouts (except in cases that won't affect screen size changes)
* The app should be converted to use the existing art assets - scaled/adjusted as needed. We will be providing additional assets during the project to replace them according to the specs required during development. The contractor needs to use the existing art for the deliverable and scale/alter it as necessary to fit the Android resolutions being developed for. If it becomes apparent that the existing artwork is insufficient for developing/testing the Android application, however, then the contractor is responsible for providing placeholder artwork themselves and communicating the art requirements to us in the next status report so that we can replace the placeholder version. The contractor should also be prepared to import additional or new art assets we create based on their feedback as part of the development process.
**Android Conversion notes:**
*These notes contain information helpful in understanding the iPhone app codebase, as well as differences required in the Android version (where noted specifically).*
**API Key**
* The API key in Constants.h will be set specifically to a new Android specific key
**Authentication and Login**
* Users can login with a KaBOOM! account
* Users can login with a Facebook account, but *must* link it to a new or existing KaBOOM! account to use the app (they should be redirected to the My Settings screen to do this)
**Base 64 Encoding**
* We included a common implementation in C in the files: Base64Encoding.h, Base64Encoding.m
* These source files will be unnecessary in the Android version
* Android provides a class for Base64 encoding in: [url removed, login to view]
**Confirm Location**
* Currently the "Confirm Location" dialogue screen appears regardless of whether there really is a conflicting or nearby playground or not
**Data Model**
* The data model does not store retrieved information between app sessions
* Some functionality in the app bypasses the Data Model altogether to make JSON queries through our API (such as Favorites)
* Data for playgrounds and play dates is retrieved by "page" from the web server, although playgrounds can request a direct number of entries (and play dates should)
**Login Redirects**
* A system is implemented throughout the code to send the user to the "next" screen on the navigation stack once the login is complete
* When the current login view is popped and the user is returned to the previous screen, a catch is made to note whether they were sent from a login screen. If so, and a redirect variable was set, then the user is sent to the next screen as defined in TabViewController.m
* This system is built using viewWillAppear()
**MyLocation**
* The location services are wrapped into a singleton which is instantiated once the app's initial splash screen transitions out
* The app currently does not attempt to gain permission (if initially denied) when such functionality is requested later in the app
**Popup Reminders**
* Users will see popups until either successfully completed or they explicitly say No
* If user says "Remind me later" then they won't see that type of Popup during their session
* Popups have a random chance of occurring when switching between tabs
**Sharing**
* The sharing screen is centralized between sharing the app, a playground, or a play date through various social means
* If accessed directly from the Help/Feedback menu, then it uses the default information in the class to share info about the app
* If accessed from a playground or play date, the playground/play date classes pass in specific parameters for the URL, title, description, etc
* In the case of Facebook these parameters are mostly ignored, and we embed OpenGraph meta tags in the website for urls ending in ?shared_from=iPhone for relevant playground/play date links
**Results Lists**
* Result list classes: [Playspace List] ResultsScreenListView.h, [PlayDates List] ResultsPlayDatesListViewController.h
* The playground (playspace) list uses a "More" button at the bottom to display an additional 20 results (or less if more are available but less than 20)
* The play dates list has not been updated to do so, but should be during Android development
* The result list classes also handle displaying maps of the current results
* There are deprecated calls to NextPage/PrevPage in the results list - this was a UI feature we never implemented, in favor of the "Load More" functionality. Please ignore these commented out sections
**Tab Bar**
* The application is built on a navigation stack controlled by the various tab buttons
* When a tab button is pressed, it resets the stack and starts from the screen associated with the given tab
* The "Favorites" tab catches attempts to view Favorites by users who aren't logged in, and redirects them to a login page
* The "RootViewController*" is [Tab Bar 1], though it is not titled in its own group like the other tab bar screens
**Trivia**
* The trivia generator contains hard-coded strings
* The "Searching? Trivia" screen is used as a loading screen for search results
**Webviews and HTML**
* HTML is used throughout the app to render static content requiring rich text formatting
* In some places, clicks on hyperlinks are intercepted in the webview and redirected to the external browser (as the in-app webview is insufficient)
---
**General**
* The app is intended for a U.S. audience (50 states, excluding some territories - see [url removed, login to view] for full list)
* Geocoding (forward and reverse) is required
* If location services and GPS don't work for searching in the contractor's area, then they need to verify that they *are* receiving coordinates from GPS (or location services), and replace those coordinates with ones for Washington D.C. for testing. This replacement *can* remain in the final deliverable: we simply require that location services/GPS be working and a place be made available for us to alter the hard-coded coordinates being used for development.
**User Interface**
* In many cases tableviews were used when unnecessary to maintain a consistent UI feel. If tableviews are only being used as a graphical display enhancement (and not to display dynamic information), then the implementation should change to being textfields on top of similar looking artwork (see the KaboomLogin for an example of this in action).
* Keyboard flow is not implemented correctly in several places, making the user experience annoying/troublesome. Care should be taken in the Android version to always maintain a consistent "user knows what to press to go to the next field/option" feel, and so the user knows how to complete actions (such as logging in).
* The app only needs to support the Portrait layout, not Landscape
**Other**
* "Playspace" and "Playground" are used synonymously throughout the code
---
**iPhone Project Structure**
*Included in the attached file "iPhone Project [url removed, login to view]"*
* * *This broadcast message was sent to all bidders on Wednesday Jul 6, 2011 3:27:50 PM:
Attention bidders! We have just updated the detailed requirements in the project description, and added useful information to help you bid. Please carefully review our requirements, as we will be choosing a final bid in the next 24 hours.
Rif. progetto: #3421872
Info sul progetto
Assegnato a:
20 freelance hanno fatto un'offerta media di $10405 per questo lavoro
