Developing Open Source Mobile Messaging and Sync Apps for ...

baroohspottyΚινητά – Ασύρματες Τεχνολογίες

19 Ιουλ 2012 (πριν από 4 χρόνια και 3 μήνες)

318 εμφανίσεις

Developing Open S ource
Mobile Mes s ag ing and S ync
Apps for iPhone vs. Android
iPhone developer summit, NYC - March 2008






A quick comparison


Innovative user experience

One manufacturer/One

COCOA based

Not completely open

Local applications not
available yet (June)

Dev tools for Mac only


Innovative SW design

No devices yet, but ready to
support a variety of them

Java based

...Yet another Java
programming paradigm..

Documentation and bug
tracking is not yet in line
with the aim of the project
Local or remote?

No download

Always up-to-date

Easy development

No network? No app.

Faster user experience



Local storage
The two platforms renewed an old question, which is flying around for years
in the computer world.
Bottomline: for mobile more than for desktop, local apps
synchronized with the network seems to be the answer for most
uses, and the iPhone SDK just confirm this.



Developing on Android

Based on Linux:




Java-only interface:

Fast development



Application separation:

Each app running on a VM,
with own user/group

New paradigm for
User/Provider separation
Application anatomy

There are four building blocks to an Android application:

represent a screen of the app. Moving from one activity to another is
done using an Intent

describes what an application wants done, in terms of the action and
the data to act upon, e.g. PICK a contact

Intent Receiver
it is used when you want code in your application to execute in reaction
to an external event, e.g. when the phone rings

is code that is long-lived and runs without a UI, like a sync session

Content Provider
is a class that implements a standard set of methods to let other
applications store and retrieve the type of data that is handled by that
content provider
Life Cycle of an Android Application

Android application runs in its own Linux process

The process lifetime is handled by the system, not by the
app: when the system needs memory to run new
applications, one of the background app is killed

That's why it is important to use correctly Activities,
Services and IntentReceivers

Not using them in the right way can result in the system
killing the application's process while it is doing important

Example: starting a thread to download a file from an Activity or an
IntentReceiver. A Service should be used instead.
Process priority

Android determines which process to kill when low on
memory with this priority:

Foreground process
: is one that is required for what the user is
currently doing (UI interaction, handling an Intent, etc.)

Visible process
: is one holding an Activity that is visible to the
user on-screen but not in the foreground (a foreground window
leaves this visible in the background)

Service process
is one holding a Service that is invisible to the
user, but is doing something valuable (e.g. Playing music)

Background process
: is one holding an Activity that is not
currently visible to the user

Empty process
is one that doesn't hold any active application
components. It is kept only as a cache to improve startup time the
next time an application's component needs to run
Application example

To make a sync application for Android, you should have:

An Activity controlling the main UI (start sync, choose items)

Some other activities for settings, About, etc..

A Service to actually doing the sync

When the user clicks on the Sync button:

The Activity triggers the service using startService() with an Intent,
which can call the service class directly, or just contains the info:
SYNC a data type, if the Service has been registered with an
appropriate IntentFilter

The service is started and the method onStart() is called. Here the
underlying sync engine provided by the Funambol SDK is started.

The Service talks back to the app using Intents to notify the sync



iPhone architecture

It is based on Mac OS X, optimized for mobile

ARM CPU, 4/8/16 Gb storage

Touch screen, proximity sensor, accelerometer, ambient
light sensor, multi-touch sensing

Text input: virtual keyboard with spell checking and
predictive input

Phone, PDA and iPod features
Developing (hacking) on iPhone

the SDK announcement, the only way to play with
iPhone local apps was to jailbreak it and get root access

From that point on you have a full unix box: this means that
you have access also to all the common C/C++ libraries
that you have on a desktop

Porting a desktop command-line app is immediate in this

Building a COCOA UI is as easy as it is on MAC

The interaction between the ported C++ code and the
COCOA UI requires some wrapping code
Funambol native sync client

The current client prototype is based on:

The Funambol C++ SDK:

Portable C++ API to build a generic Syncml client

Easy binding with client datastore through SyncSource interface

a command line client, SyncEvolution:

initially made for Novell Evolution

developed by a Funambol community member, Patrick Ohly

The client has been compiled for iPhone and a connected
to the (undocumented) AddressBook interface

A simple COCOA user interface -- the game is done!

But... you need a jailbroken device to run this

Next: we are designing the new version of the client, based
on the Apple SDK
Developing with the iPhone SDK

iPhone OS has a structure
similar to the Mac OS X,
optimized for a touch based
mobile device

The SDK exposes most of
the iPhone OS features to
the developer

An application access from
the low-level C interfaces of
the Core OS up to the
ObjectiveC Cocoa Touch

Application distribution
through iTunes
Application lifecycle

One app at a time running
on the system

The app is notified when
started by the method:

The app enters the main
event loop

The app is notified when the
user moved away from it

The app must save its state
and close within few
seconds, then it is
destroyed by the system
Security schema

Application sandbox:

The app can access only its
own files and data

The app files are all located
under the application home
directory, with the reference
structure shown in figure

The app can access also a
limited set of network and
hardware resources

Sandboxing prevents a
defected or attacked app to
corrupt other apps or the
Integration features

Accelerometer events

From just knowing the right screen orientation, to movement-
controlled graphical games

Get user's location

Location-based advertising, services, games...

Take Pictures

Pick photos from the photo library

Access contacts in the AddressBook
Limits of the SDK

No background process?

The SDK documentation states an app must close when the user
leaves it

How to build applications which need to listen for network events
even after the user leaves it? (IM, email, sync)

No public calendar interface?

How to interact with the calendar application without it?

No official email integration:

Is it possible to deliver email other than with the apple client and
built-in protocols?

No application autostart:

How to implement any 3
party app which starts and run like a

You need Apple to distribute your app (good and bad..)

Funambol Software:

Open Source page:

Funambol community support:

Android Client:

iPhone Support page:

C++ SyncML API:


Iphone developer site:
Thank you.