How is you mobile apps interacting with your cloud backbone. What kind of impact does your app create in your users under the hood.

1. Synchronization Architecture
for
Cloud powered Mobile Apps
Prithiviraj Damodaran
www.ByteContinnum.com

2. Major Concerns Addressed 1 of 2
From the App User and Device Resource view point the
following are some of the critical factors a cloud backed
mobile engineering team should consider.
• Smart Disk space usage - A lot of apps including some
popular social media apps abuse device disk space. Every time the
apps sync with the cloud counter part they bring down fresh data.
Apps should be considerate of device user and should come up with
some clean-up mechanism.

3. Major Concerns Addressed 2 of 2
• Smart Network usage – Be it upstream or downstream sync
i.e. apps as well as the cloud counter parts should be designed to be
very frugal about the number of bytes sent over the wire as well as
the number of network calls as it directly impacts the data usage and
hence the device user.
• Smart Battery consumption -
For instance
• Apps which broadcast real time user activities should smartly club
syncs to reduce multiple device pings
• Location and geo fence based apps should use the right strategy to
avoid draining device battery.

4. Event Driven Synchronization
Cloud-2-Device
• On-AppStartup
• On-AppBackground2Foreground Transition
• On-AppSignin (if any)
• On-Demand user action
Device-2-Cloud
• On-AppUITransition

5. Cloud-2-Device

6. On-Start-up - online
• First time fetch of current Location
• Instantiate N/W Connection receiver. (Wifi/Data)
• “All” data if new device or “Newer” data
deals since last sync date, if used device.
• Clean up older disk cache records. (Cache date <
Current date and un synchronized)
• Any other Metadata sync or change in Business rules or
disclaimers etc..

7. On-Start-up - offline
• If new device change to offline mode and provide an option
to retry N/W connection
• Active fetch of current Location.
• If used device use last synced data
• Clean up older disk cache records. (Cache date <
Current date and synched)

8. On-Sign in
• User data later than last sync if already used device -
Something like getting the newer emails from the server since
last sync. Using the app in Multiple devices doesn’t affect this
part of the sync. But it does affects the synch of user specific
settings/ preferences.
• User specific notifications – offers or expiry notices etc.
Since there could be multiple devices in which user could login
from, every device will have to maintain last sign in timestamp
and Cloud will maintain last synchronization timestamp at levels
desired. Every time during sign-in If these 2 time stamps vary
then it calls for Synching all user specific settings data
• User specific app settings and preferences

9. On-Sign in - offline
• show the message and continue as guest in offline mode.

10. On-Demand Sync – 2 Way
• All data listing screens shall support on-Demand sync.
Using a pull down or swipe down gesture user can initiate sync.
• During swipe down n/w state will be first checked before
making the Sync call. If offline appropriate message shall be
shown.
Best real life example would be your Gmail app.
Try to “star” an email and Swipe down. Your “star” should
reflect in your server (try and open gmail in another device or
PC) and if you had new emails that would be in your device too.
So 2 way cloud sync.

11. On-Demand Sync – 2 Way
1
2
3
Rest APIs

12. Device-2-Cloud

13. On-UITransition
• All user activities shall be stored at disk first and synced on the
next UI based action like a UI Transition. The approach is
disk first and asynchronous calls to cloud. The stored data shall look
something like below. Choice of storage could be disk caches like
SQLLite or something similar.
Data Cache Date Sync Status
{“test”:”data”} 2014-08-01:00:00:00 Sync Progress
{“test”:”data”} 2014-08-01:00:00:00 Sync Complete
{“test”:”data”} 2014-08-01:00:00:00 To be Synced

14. 1
2

15. Offline mode
As a part of the strategy make sure all deal breaking features
(whichever possible) are supported in offline mode for the
success of the app. This might require some careful planning
and some extra processing / storing required data in the
device.