The aim of this project is the development of an application for android
and the iPhone that allows the user to use a photo community where one
can rate existing pictures as well as upload pictures to the platform for
participation in various "contests", in which case the user has to deposit
some amount of money per picture uploaded. Please don't worry too much
about the purpose of this, just take the requirements as specified - we
don't want to and in part can not explain in detail the ideas behind this.
This specific request is for an application for iPhone. We also want
to have the same application for Android, the request for which
you find over here. We are also interested in combined offers if you
would be interested in implementing both applications at a correspondingly
lower price. The remainder of this text is not specific to one platform -
whereever there is a reference to the platform that's not the subject of
this request, feel free to ignore it.
These functions are to be implemented in the application:
* authentication of the user to the platform
* download of pictures and displaying them to the user
* allow the user to rate the displayed pictures
* allow the user to upload pictures
In addition, the following functions should be accessible through the
application, but only in the way of invocation of a web browser for
a specific URI:
* registration of new users
* management of the user's micropayment account
The interface to the backend/the platform will be provided through
HTTPS, using JSON for the serialization of messages. You can find a
detailed specification of the API as currently implemented among the
attachments. The API is not set in stone if you can make a good case
for some change.
## Deliverables
= Preamble
Pretty much everything in this request is negotiable. Please either
get in touch with us in advance to discuss, or specify in your offer
in which ways you wish to deviate from what we propose. If possible,
please provide some justification for us to consider.
This specific request is for an application for iPhone. We also want
to have the same application for Android, the request for which
you find over here. We are also interested in combined offers if you
would be interested in implementing both applications at a correspondingly
lower price. The remainder of this text is not specific to one platform -
whereever there is a reference to the platform that's not the subject of
this request, feel free to ignore it.
If there is anything unclear about our requirements, please don't
hesitate to ask.
= Summary
The aim of this project is the development of an application for android
and the iPhone that allows the user to use a photo community where one
can rate existing pictures as well as upload pictures to the platform for
participation in various "contests", in which case the user has to deposit
some amount of money per picture uploaded. Please don't worry too much
about the purpose of this, just take the requirements as specified - we
don't want to and in part can not explain in detail the ideas behind this.
These functions are to be implemented in the application:
* authentication of the user to the platform
* download of pictures and displaying them to the user
* allow the user to rate the displayed pictures
* allow the user to upload pictures
In addition, the following functions should be accessible through the
application, but only in the way of invocation of a web browser for
a specific URI:
* registration of new users
* management of the user's micropayment account
The interface to the backend/the platform will be provided through
HTTPS, using JSON for the serialization of messages. You can find a
detailed specification of the API as currently implemented among the
attachments. The API is not set in stone if you can make a good case
for some change.
= Operation in Detail
== General Screen Layout
* Among the attachments you find some drafts of our ideas as to how
to organize the UI. That PDF is supposed to visualize structure
only, the style of the UI should match the target platform.
* An "upload" button should be displayed on the screen.
In the iPhone version of the application, there also should be a
"menu" button, the android version should use the hardware menu
button for that purpose.
* The menu should provide for an option to purge authentication
credentials.
== Localization
We would like to be able to provide localization information
(translations, that is) through the server. The application
should request the translation according to the device's language
settings from the server at every startup.
Please specify with your offer how we would have to create
translations (format, possibly tools to use for conversion).
== Authentication
Some of the backend's operations require authentication, some accept
optional authentication, but also allow anonymous access. The API's
documentation specifies which of the two categories each of the operations
falls into.
In order to implement the "optional authentication" scheme,
the application should have a persistent asked-for-credentials flag which
is false initially (after installation, that is). Whenever the application
is about to send a request to the backend and either the
asked-for-credentials flag is false or the operation to be performed
requires authentication, it should ask the user for credentials.
If the operation does not require authentication, the user should be
provided with the option to bypass authentication. Whether the user
chooses to enter credentials (which are to be persisted in the form specified
in the API specification) or to bypass authentication, the
asked-for-credentials flag should be set to true.
When the reply to some request indicates invalid credentials, or when
the user selects removal of authentication credentials from the
menu, the asked-for-credentials flag should be reset to false, thus
causing the user to be re-prompted before the next request/retry is sent.
Also, the authentication dialog should provide an option to launch
a web browser for the URI of the web interface's new-user registration.
== Error Handling
Apart from the specific error handling as specified in the API
specification, connection problems when talking to the server should
lead to a dialog informing the user about the situation and
giving him the opportunity to initiate a retry. All operations
of the API are idempotent, so there are no exceptions to this rule
that you would have to take care of, even with operations that have
side effects.
Any error conditions should be signalled with a message that
gives some indication of what went wrong technically, so that
at least technical support does have a chance of tracking down the
cause of the problem.
== Usual Sequence of Operation
=== Rating
* When launched, the application should request a random picture to
display from the server.
* The picture (in JPEG format) will be sized such that its long edge
will be at most 480 pixels, its short edge at most 320 pixels (or both
at most 320 pixels in case it's square). It should be rotated to align
its long edges with the long edges of the display and the short edges
with the short edges of the display (for square pictures, do whatever
you like), and scaled, preserving the aspect ratio, to fill the display
in at least one dimension, not exceeding it in any dimension. The UI
elements should be placed according to the device's UI orientation,
regardless of any rotation applied to the picture.
* A translucent "!" (good picture) and a translucent ">" (next picture)
should be displayed overlayed on top of the picture which the user can
select in order to rate the picture. If the "!" is selected, it should
be highlighted for two seconds before proceeding. If the "!" is selected,
a value of 1 is to be submitted as the rating value, if the ">" is
selected, a value of 0 is to be submitted.
* In the reply to the request telling the server the rating, the server
provides the information about the next picture to display.
=== Upload
* When pressing the "upload" button, the user should be presented
with a list of available contests (which can be requested from the
server), listing the description as well as the amount of money
he'd have to deposit in order to submit a picture to that contest.
* After selecting one contest, the user should be presented with
an overview of all the pictures on the device (or whatever
mechanisms usually are used for such purposes on the platform)
in order to select one for upload.
* Before actually uploading the picture, the application should
validate that the picture fits within constraints specified by the
server as part of the contest list. The constraints will be:
** minimum number of pixels
** maximum number of pixels
** minimum aspect ratio
** maximum aspect ratio
* During upload, a general "in progress screen" is displayed, no
fancy progress bars or stuff required (see below, though).
* The server's reply to the upload contains the current balance
of the user's micropayment account.
** If sufficient money is available in the user's account in order to
submit the picture to the selected contest, a verification screen
has to be displayed. This verification screen should inform the user
about the amount of money he is about to deposit and the current balance
of his micropayment account, and he has to accept the terms of service as
well as a clause assigning rights to the platform operator by means of
checkboxes or similar. The complete text of the TOS should be made
available for viewing through some button, it can be requested from
the server under a URI specified in the API specification in utf-8
plain text. When the user accepts, this is submitted to the server,
the user is informed about the completion of the transaction, and then
can return to the rating screen with a new random picture.
** If there is not sufficient money available in the user's account,
the user is informed about this fact and given the option to launch
a web browser for the URI where the user can manage his micropayment
account. No provisions have to be made to handle completion of the
upload within the application in this case, the user will have to do
that through the web interface in this case.
= Optional Functions
For these, please quote separate prices for each function that you would
be willing to implement:
* Display of the partial image during download.
* Down-scaling of the picture to be uploaded to the minimal size that's
still larger than or equal to the minimum specified by the server (the
validation limit mentioned above), preserving aspect ratio. The result
should be a JPEG with a compression setting that would also be specified
by the server if possible (fixed value may also be OK). Please specify
what resampling algorithms you would want to use.
* Progress bar during upload, displaying amount to be transmitted and
amount completed (relative (%) and absolute (kByte)) plus an estimate
of the current transfer rate.
= Miscellaneous
* You are free to select any programming language(s) you want to use.
Please specify in your offer which language(s) you would use.
* You should provide documentation, in particular:
** Dependencies (for building).
** Instructions for making the application available in the app store
of the platform (signing and the like).
* We also expect you to provide some support with making the application
available in the app store of the platform in case we don't manage
to do that by following your documentation.
* Identifiers in the code, comments, documentation, and user interface
should be in English (plus the localization mechanism eplained above,
but you don't have to provide translations yourself).
* You should provide some automated build system (Makefile or whatever
seems appropriate) that allows the application package to be built
from source with minimal manual intervention (essentially, one command
should do).
* We expect you to use git for version management, pushing to us every
day that you worked on the project. You should write sensible commit
messages for your changes so we do have a clue what's going on.
* You should provide a short report on the state of the development
twice per week (to be provided for tuesday and friday in UTC,
respectively).
* Please specify with your offer how much test coverage you would aim
for (if any).
* A test backend server for you to test your code against will be
provided the day we award the contract.
* The application has to verify the server's X.509 certificate, rejecting
any invalid certificates, without any fallback when verification fails,
even the user should not be allowed to override verification failures.
* The application should conform to the platform's recommendations
concerning the use of APIs, UI layout and the like - at least as far as
that is sensible; where such recommendations are moronic or otherwise not
so wise for the purpose, please discuss it with us.
* Suggestions of alternative solutions for anything we specify are welcome
(for example, if there are simpler/cheaper or (technically) better
solutions available), please indicate in the offer or discuss with
us in advance.
* We provide a trac or a redmine (if requested/required).
* Please specify an hourly rate for changes/extensions beyond the
extent of this contract.
* You should make us aware if (as far as you are aware) our application
is in conflict with any rules that apply to publishing the application
to be developed under this contract in the platform's application store.
* Artwork will be provided by us. If you need any graphics for the UI,
let us know, we'll produce what's needed.
= Legal
* The application has to be free from claims of third parties.
** If you want to use open source/free software components, you may use
anything that can be relicenced under a proprietary licence for us to
use and redistribute the application binary without source or where the
licence does already directly allow such use. If in doubt, please ask
whether a specific license is OK to use. GPL and other copyleft licences
almost certainly are not OK, BSD-style probably is OK, LGPL may be OK.
* All rights concerning use and redistribution of the application,
including its source, will have to be assigned to us exclusively.
* The deadline for completion of the project will be 21 days after
conclusion of the contract. The contract will be awarded 2010-06-07 latest.
If the application is not finished on time, you will have to pay a
contractual penalty of 5% of the contract value per day.
* We guarantee a reply latency of at most 72h for any questions on your
part concerning the implementation of the application. When the 72 hours
are over, you have to remind us of the pending questions. The deadline
then will be extended by the amount of time between your reminder and our
answer to your questions.
* The contract will be made under German law.
= Code Guidelines
* use consistent indentation (either tabs or spaces)
* choose sensible English names for identifiers (e.g. "reply" instead
of "doAction")
* comment code where appropriate, don't comment every single line, don't
duplicate the code's behavior in comments
* use plain-text files for all documentation purposes
(i.e. don't use PDF or MS Word documents!)
* Make your code Unicode clean. Suggested Test-Data: Iñtërnâtiôn? lîzætiøñ