Mo­bile App De­vel­op­ment in the Fast-chang­ing Mo­bile Phone In­dus­try

Change is the only con­stant in the IT in­dus­try, and this change has been par­tic­u­larly dra­matic in the case of the mo­bile phone in­dus­try. Let’s take a quick look at the trans­for­ma­tion in this in­dus­try over the last two decades, and how this has im­pacted mo

OpenSource For You - - Contents - By: Gau­rav Vohra The au­thor is a se­nior so­lu­tion ar­chi­tect at Im­pe­tus Tech­nolo­gies and has more than 13 years of ex­pe­ri­ence in the IT in­dus­try. He has been pre­dom­i­nantly han­dling soft­ware prod­ucts and ser­vices in the en­ter­prise mo­bil­ity & dig­i­tal mar­ketin

Mo­bile de­vices have changed dras­ti­cally, start­ing off from Nokia’s ba­sic fea­ture phones, mov­ing to Black­Berry’s smart/business phones, and then to the rev­o­lu­tion­ary Google and Ap­ple smart­phones. With time, hardware has im­proved with in­creas­ing RAM and pro­ces­sor ca­pa­bil­i­ties. To­day, there are lot of cool hardware be­ing built into phones to make them com­plete de­vices, right from cam­eras and GPS to ac­celerom­e­ters and fin­ger­print read­ers.

Over the years, plethora of mo­bile OS/plat­forms have been cre­ated and launched by com­pa­nies like Sun, Qual­comm, RIM, Mi­crosoft, Google and Ap­ple — right from J2ME/BREW to Black­Berry (RIM), and An­droid, iOS and WP8. All these plat­forms sup­port dif­fer­ent na­tive API suites and vary in terms of the frame­work they of­fer. In fact, the base pro­gram­ming lan­guages of these plat­forms have been dif­fer­ent. Java was used for J2ME, RIM and An­droid, while C++ was used for BREW, C#/C++ for WP8 and Ob­jec­tive C for iOS.

With the mo­bile mar­ket be­ing shared by these dif­fer­ent plat­forms/OSs, till a few years back it was dif­fi­cult for de­vel­op­ers and com­pa­nies to cre­ate mo­bile ap­pli­ca­tions for all plat­forms. It needed a di­verse set of skills to de­velop and main­tain mo­bile ap­pli­ca­tions for each of the mo­bile plat­forms and, thus, pre­sented cost and time-to-mar­ket chal­lenges.

The al­ter­nate means tried in­cluded cre­at­ing hy­brid apps (Web based ap­pli­ca­tions wrapped in na­tive mo­bile app con­tain­ers). Hy­brid apps had their own lim­i­ta­tions and were de­fi­cient in terms of per­for­mance, user en­gage­ment and ef­fec­tive util­i­sa­tion of de­vice hardware ca­pa­bil­i­ties.

The re­cent in­no­va­tion of bot plat­forms has in­tro­duced new pos­si­bil­i­ties for cre­at­ing de­vice and plat­form neu­tral apps. In the long run, bots (chat-bots) are pre­dicted to sub­sti­tute a ma­jor chunk of mo­bile apps. Though new, bot plat­forms are limited in terms of the API set, fea­tures and ca­pa­bil­i­ties, as of date.

Hence, con­sid­er­ing the di­verse OS ecosys­tem, a mo­bile ap­pli­ca­tion de­sign and de­vel­op­ment strat­egy be­comes very im­por­tant. A smart, strate­gic ap­proach al­lows sup­port­ing mul­ti­ple OSs/plat­forms and de­vices, with­out com­pro­mis­ing on as­pects like per­for­mance and user en­gage­ment.

This ar­ti­cle is based on my years of ex­pe­ri­ence in de­sign­ing and de­vel­op­ing games as well as con­sumer and en­ter­priseg­rade rich mo­bile client ap­pli­ca­tions for all the ear­lier men­tioned plat­forms. In­di­vid­ual de­vel­op­ers or or­gan­i­sa­tions that plan to de­velop mo­bile client ap­pli­ca­tions may find my ex­pe­ri­ences help­ful in de­cid­ing on the most suit­able mo­bile de­sign and de­vel­op­ment strat­egy, af­ter eval­u­at­ing the pros and cons of each. I in­tend to share in­for­ma­tion about dif­fer­ent mo­bile OSs/plat­forms for dif­fer­ent era, the chal­lenges they pre­sented at the time, fol­lowed by the de­sign and de­vel­op­ment strat­egy adopted to deal with those chal­lenges.

Early 2000s: The era of fea­ture phones with J2ME/BREW apps

Dur­ing the early 2000s and un­til around 2004, BREW and J2ME games and apps were pre­dom­i­nant in the mar­ket. The rea­son was sim­ple — peo­ple were us­ing fea­ture phones and they needed light­weight plat­forms. Most fea­ture phones sup­ported ei­ther J2ME or BREW.

Qual­comm’s BREW was based on C/C++. On the other hand, J2ME (Java 2 Mi­cro-Edi­tion) was a stripped down ver­sion of Java’s Stan­dard edi­tion, with a limited API set meant for de­vices with min­i­mal hardware. It was mostly used to build light­weight games, and ba­sic ap­pli­ca­tions for fea­ture phones with limited func­tions, like those re­lated to PIM (Per­sonal In­for­ma­tion Man­age­ment). J2ME de­vices hardly al­lowed any­thing re­lated to sys­tem/hardware in­ter­fac­ing and even if they did, things rarely worked as in­tended. This limited J2ME to be used mostly for gam­ing ap­pli­ca­tions on fea­ture phones and not for any so­phis­ti­cated client ap­pli­ca­tion.

The chal­lenges - poor hardware, as well as limited APIs and multi-task­ing: The early fea­ture phones came with quite a few chal­lenges.

1. Build­ing games or apps on J2ME was chal­leng­ing ow­ing to limited hardware ca­pa­bil­i­ties. Many of the phones al­lowed a max­i­mum of 64KB of JAR (J2ME bi­nary size) and/or al­lowed 128KB of RAM. Even the most pop­u­lar J2ME de­vice in 2005, the Nokia 6600, sup­ported 1MB of RAM for J2ME apps.

2. Also, since the API set was very limited, it only en­abled the cre­ation of very ba­sic ap­pli­ca­tions.

3. Multi-task­ing was miss­ing on most of the fea­ture phones. J2ME apps used to pause as soon as they were moved to the back­ground.

Al­ter­na­tive ap­proaches to deal with small RAM and app bi­nary sizes: Over the years, the de­sign and de­vel­op­ment strate­gies adopted to over­come dif­fer­ent chal­lenges in­cluded the fol­low­ing.

1. Apps were pack­aged with very few re­sources (im­ages), while other re­quired re­sources were fetched once from the server via data calls and then cached lo­cally to the record man­age­ment sys­tem.

2. Apps were de­signed to load only a por­tion of the data or re­source (im­age) re­quired at any mo­ment of time. Later, loaded re­sources were re­placed with other re­sources needed for sub­se­quent flows. For ex­am­ple, for one of the gam­ing ap­pli­ca­tions (Shadow Show­down’s FOP), we chopped the big im­age of a char­ac­ter an­i­ma­tion into three in­de­pen­dent parts to keep the mem­ory in check by op­ti­mis­ing the size of the im­age part. We then used one part of the im­age at a time and then re­placed it with an­other part when needed.

3. Usu­ally, ba­sic apps were built with­out a rich API set and no multi-task­ing.

2005-09: The Black­Berry era her­alds the first smart, business phone

Roughly be­tween 2005 and 2010 was when Black­Berry phones en­joyed the most pop­u­lar­ity. Black­Berry from RIM (Re­search in Mo­tion) was the first smart­phone in­tro­duced in the league of phones/plat­forms dis­cussed in this ar­ti­cle. Be­cause of its se­cu­rity, it was con­sid­ered the best business phone and pre­ferred by en­ter­prises. Black­Berry had its own OS, which pro­vided multi-task­ing and ini­tially sup­ported de­vices with a track­wheel and track­pad. The brand had many pop­u­lar se­ries of phones, like Curve, Pearl and Storm, to name a few.

Black­Berry pro­vided a Java based API set. With rich APIs and multi-task­ing sup­ported by the OS, it be­came pos­si­ble for de­vel­op­ers to build so­phis­ti­cated na­tive business apps which hadn’t been the case for J2ME apps. Be­ing able to use builtin de­vice ca­pa­bil­i­ties al­lowed apps to have fea­tures like file op­er­a­tions, na­tive email, phone and SMS.

Rich ap­pli­ca­tions, right from Reuter’s stock mar­ket app and the Stitcher ra­dio (au­dio) app to OpenTable’s restau­rant book­ing app and Broad­works As­sis­tant VoIP call­ing back­ground app, were all pos­si­ble with RIM. Yet, cre­at­ing mo­bile web­sites or Web based ap­pli­ca­tions wasn’t fea­si­ble ow­ing to very limited JavaScript sup­port.

The chal­lenges: Some of the main short­com­ings of the Black­Berry in­cluded a small dis­play, a com­plex UI API, an old Web kit and dif­fi­cult back­ward com­pat­i­bil­ity.

1. One of the big­gest chal­lenges for Black­Berry’s pop­u­lar

4.x de­vice se­ries (that in­cluded Curve and Pearl) was de­sign­ing the UX and im­ple­ment­ing it. Black­Berry phones al­ready had only a sin­gle column view com­pared to screens that per­mit­ted the multi-column view for a wider Web area. On top of this, the hard key­pad hin­dered the pos­si­bil­ity of in­creas­ing the dis­play height ef­fec­tively.

2. The only way to cre­ate a user in­ter­face (UI) for Black­Berry’s Java apps was by us­ing RIM na­tive APIs.

The UI API set and lay­out prin­ci­ples were com­plex, and this made it dif­fi­cult to de­velop a rich UI.

3. The ma­jor­ity of Black­Berry users in the mar­ket had the old RIM OS ver­sion (4.x se­ries) run­ning on their de­vices, and the Web kit en­gine that came with 4.x was limited in terms of func­tion­al­ity and JavaScript ca­pa­bil­i­ties. Hence, build­ing mo­bile web­sites be­came re­ally dif­fi­cult. I re­mem­ber that build­ing an in­ter­ac­tive Web calendar con­trol be­came al­most im­pos­si­ble for the Black­Berry OS 4.x se­ries.

4. RIM sup­ported static class ver­i­fi­ca­tion, that is, if an app was com­piled and pack­aged with a higher OS ver­sion’s na­tive li­brary API suite and pos­sessed a higher OS API, then the pack­aged app would not in­stall on de­vices with old OS ver­sions. This made it dif­fi­cult to en­able back­ward com­pat­i­bil­ity while cre­at­ing apps tar­geted for lat­est OS ver­sions.

Deal­ing with the chal­lenges: Listed be­low are some of the de­sign and de­vel­op­ment strate­gies used to over­come the dif­fer­ent chal­lenges.

1. All key mod­ules were served as Home Screen op­tions, af­ter which stan­dard lin­ear or tabbed (for big apps) nav­i­ga­tion fol­lowed.

2. A reusable cus­tom com­pounded and UI com­po­nent li­brary was cre­ated. This was done by ex­tend­ing stan­dard con­tain­ers and com­po­nents (like a field man­ager, ver­ti­cal/ hor­i­zon­tal field man­agers, la­bel/text fields, etc).

3. As 4.x de­vices cov­ered a ma­jor­ity of the mar­ket ini­tially, na­tive RIM ap­pli­ca­tions were the only op­tion un­til the

launch of RIM OS 6.x/ 7.x se­ries with the Web kit 2 en­gine dur­ing late 2010-12.

4. Back­ward com­pat­i­bil­ity was smartly achieved by com­pil­ing a base ver­sion of the app with the min­i­mum OS ver­sion sup­ported by it. For all add-on delta fea­tures, add-on bi­nary files were cre­ated for the app with a higher OS API and ad­vanced func­tion­al­ity. The base code had a smart fac­tory to check which OS ver­sion the app was run­ning on, and dy­nam­i­cally loaded the im­ple­men­ta­tion of the higher OS ver­sion if the de­vice had the re­quired OS ver­sion. While dis­tribut­ing the app, the dis­tri­bu­tion server would check the OS ver­sion of the de­vice re­quest­ing the app down­load. For higher OS ver­sions, the dis­tri­bu­tion server could load the JAD (Java ap­pli­ca­tion de­scrip­tor) file, which pos­sessed en­tries of all bi­nary files, in­clud­ing the base bi­nary pack­aged with the min­i­mum OS as well as add-on bi­nary files pack­aged with higher OS ver­sions to achieve ad­vanced func­tion­al­ity.

2010: How An­droid and iOS trans­formed the mo­bile in­dus­try

The mo­bile in­dus­try un­der­went a dis­rup­tive trans­for­ma­tion with the launch of An­droid and iOS dur­ing the years 2008-10.

Google’s An­droid and Ap­ple’s iOS were launched to run on high-end mo­bile de­vices (like HTC, iPhone, etc). These de­vices were not just mo­bile de­vices but were al­most small com­put­ers with great pro­cess­ing and com­put­ing ca­pa­bil­i­ties. They had a lot of use­ful hardware built-in, like GPS re­ceivers, cam­eras, ac­celerom­e­ters, etc. An­droid and iOS pro­vi­sioned na­tive APIs to ac­cess and use these built-in ca­pa­bil­i­ties within ap­pli­ca­tions.

Along with such great hardware ca­pa­bil­i­ties, both An­droid and iOS came up with full touch­screen de­vices with­out hard key­pads. This en­sured that most of the screen height be­came us­able and thus en­hanced the us­abil­ity of ap­pli­ca­tions. Ex­cel­lent ges­ture de­tec­tion and touch ca­pa­bil­i­ties of these de­vices pro­vided an ex­tra­or­di­nary user ex­pe­ri­ence.

The chal­lenge: J2ME, BREW and RIM were al­ready around, and with the launch of iOS and An­droid, the mo­bile in­dus­try was us­ing sev­eral mo­bile plat­forms be­tween 2010 and 2012-13. Dif­fer­ent plat­forms with dif­fer­ent na­tive APIs made it re­ally dif­fi­cult for de­vel­op­ers/com­pa­nies to build apps for mo­bile users.

It now be­came im­per­a­tive for de­vel­op­ers and com­pa­nies to sup­port all these plat­forms to cover the en­tire mar­ket. With dif­fer­ent na­tive APIs and dif­fer­ent base lan­guages, the task be­came re­ally chal­leng­ing. It re­quired a dif­fer­ent skillset to build mo­bile apps for dif­fer­ent plat­forms, and this in­creased costs and time-to-mar­ket sub­stan­tially, be­cause dif­fer­ent ver­sions of an ap­pli­ca­tion were built and main­tained for each plat­form. Do­main knowl­edge couldn’t be reused with dif­fer­ent teams which re­sulted in in­con­sis­tent app be­hav­iour.

Web/hy­brid apps: The in­dus­try was strug­gling with the many vari­a­tions around mo­bile plat­forms and APIs. More­over, there were new mo­bile OSs/plat­forms, which were on the verge of be­ing launched. As a re­sult, de­vel­op­ers and com­pa­nies started chan­nelling their ef­forts and en­er­gies around cre­at­ing plat­for­min­de­pen­dent, Web/HTML based mo­bile ap­pli­ca­tions.

Web kit en­gines were get­ting bet­ter with each new ver­sion of an OS. Also, the in­tro­duc­tion of HTML5 gave de­vel­op­ers the con­fi­dence to try and build mo­bile web­sites which worked across all mo­bile plat­forms. Web­site UIs got re­designed for sin­gle column view mo­bile de­vices and con­tent was then served dy­nam­i­cally with the help of JavaScript (Ajax).

Mo­bile web­sites, a.k.a. thin clients, pro­vided plat­for­min­de­pen­dent so­lu­tions but ob­served less end user adop­tion ow­ing to dif­fi­cul­ties in us­ing and man­ag­ing dif­fer­ent web­sites at the same time on mo­bile de­vices. Users al­ways pre­ferred quick app icons. Also, pure mo­bile web­sites run­ning in browsers lacked the ca­pa­bil­ity to use the in­built de­vice hardware like the cam­era, GPS, etc.

Hy­brid mo­bile ap­pli­ca­tions over­came mo­bile web­site prob­lems. They served Web based (HTML) con­tent within a na­tive mo­bile app con­tainer. The mo­bile app con­tainer houses the Web view, which loads the URL for the Web con­tent (which can be thought of as the web­site’s URL). Hy­brid mo­bile apps with a quick launch app icon freed the user from man­ag­ing dif­fer­ent web­site URLs. Ad­di­tion­ally, hy­brid mo­bile apps lever­aged the Web to na­tive bridge in­ter­faces (plug­ins), to utilise built-in de­vice hardware ca­pa­bil­i­ties within the app.

So hy­brid mo­bile apps be­came the al­ter­nate op­tion to deal with the time-to-mar­ket and cost prob­lems aris­ing from sup­port­ing mul­ti­ple mo­bile plat­forms dur­ing the pe­riod 201012. These hy­brid apps, un­for­tu­nately, soon came un­der scru­tiny due to the ad­verse im­pact of Web con­tent in terms of user ex­pe­ri­ence and per­for­mance. This led to the fa­mous dis­cus­sion on ‘na­tive ver­sus hy­brid mo­bile ap­pli­ca­tions’.

Hy­brid vs na­tive mo­bile apps: This has been a topic of much de­bate for many years amongst de­vel­op­ers and com­pa­nies wish­ing to cre­ate mo­bile ap­pli­ca­tions for dif­fer­ent plat­forms — whether to opt for na­tive or hy­brid mo­bile apps.

The best way to de­cide be­tween the two op­tions is by an­swer­ing a few ques­tions like:

1. How much does cost and time to mar­ket mat­ter to you? a. If you have a highly skilled team, and time and per­for­mance mat­ter to you, then na­tive is a bet­ter choice. A skilled team can quickly learn the syn­tax of new mo­bile plat­forms and port a na­tive mo­bile app to a plat­form.

b. If your team is small and you are tar­get­ing a quick launch for your mo­bile app, then hy­brid is the way to go, as the same code can be reused across dif­fer­ent mo­bile OSs/plat­forms.

2. Who are your tar­get users? Is it go­ing to be an in-house app meant for those within the com­pany or a pub­lic app for your cus­tomers/end con­sumers? a. If it is go­ing to be a pub­lic app for your cus­tomers, then na­tive is the bet­ter choice over hy­brid be­cause the user ex­pe­ri­ence is of ut­most im­por­tance to mo­bile users.

Re­ports on the In­ter­net sug­gest that around 80 per cent

of users only retry a mo­bile app once or at the most, twice, if it fails to work as in­tended or if it is slow. It is im­por­tant to keep users en­gaged at all times and that can be done via fast per­form­ing na­tive apps. One key ex­am­ple is of Face­book mi­grat­ing from HTML to a na­tive mo­bile app to keep users en­gaged by serv­ing more feeds at the same time.

b. If it is go­ing to be an in-house app for users within the or­gan­i­sa­tion, then hy­brid apps can work, par­tic­u­larly if the app is meant for rou­tine business op­er­a­tions. In­ter­nal apps need not be very ex­cit­ing for users, as long as they solve the pur­pose in the ex­pected time­frame.

3. What is the geography of your ma­jor­ity user base? How many plat­forms do you ac­tu­ally want to cover? a. If you are tar­get­ing just one ge­o­graphic re­gion with the launch of your app, then na­tive is a bet­ter choice, as you can just tar­get the one plat­form that com­mands the high­est mar­ket share in that ge­o­graphic re­gion

(like iOS for USA).

b. If you are tar­get­ing to re­lease your app glob­ally, then a hy­brid app can be opted for as the mar­ket will be shared by dif­fer­ent mo­bile OSs/plat­forms.

4. How big or rich does your mo­bile ap­pli­ca­tion need to be? a. If you are tar­get­ing to launch a full blown, rich mo­bile app with built-in de­vice hardware ca­pa­bil­i­ties like a cam­era, GPS, etc, then na­tive is a bet­ter choice for en­hanc­ing the per­for­mance of the app, and ef­fec­tively achiev­ing touch/ges­ture han­dling and built-in de­vice hardware ca­pa­bil­i­ties.

b. If you are tar­get­ing to launch a min­i­mum vi­able prod­uct (MVP) for your mo­bile app, then hy­brid can be the op­tion as per­for­mance may not be ham­pered much with less fre­quent Web-to-na­tive layer in­ter­ac­tions. Also, it gives op­por­tu­ni­ties to the de­vel­op­ers to try out dif­fer­ent ideas in no time — in the form of MVP of dif­fer­ent hy­brid mo­bile apps. They can later opt for the na­tive app route for ideas that gain trac­tion and, hence, need to be ex­tended and scaled in the form of a mo­bile app (the way Face­book did).

2017: An­droid and iOS lead the mo­bile mar­ket

With great tech­no­log­i­cal ad­vances con­tin­u­ously en­hanc­ing the hardware, both An­droid and iOS have be­come the most pop­u­lar choice of con­sumers to­day. With a grow­ing user base, de­vel­oper adop­tion and in­creas­ing app vol­ume on Play/App Store, An­droid and iOS are now lead­ing the mo­bile mar­ket with a ma­jor share of the global mar­ket.

As op­posed to Black­Berry, both An­droid and iOS were launched with their ini­tial fo­cus on the end user. Grad­u­ally, the lat­ter two also built se­cu­rity and APIs to cater to business and en­ter­prise needs. With these plat­forms lead­ing the mar­ket and with the grow­ing BYOD cul­ture, both these plat­forms have be­come the choice for business apps as well.

Ease of de­vel­op­ment via an easy and great API suite have re­sulted in de­vel­op­ers and com­pa­nies quickly adopt­ing these two plat­forms. As a re­sult, all other mo­bile plat­forms/

OSs like J2ME, RIM, and even Win­dows Phone, which came into the mar­ket late, have lost their limited mar­ket share and al­most van­ished. This has solved the cost and time-to-mar­ket prob­lem caused by sup­port­ing mul­ti­ple mo­bile OSs/plat­forms. De­vel­op­ers/com­pa­nies can now just cre­ate apps for An­droid and iOS. More­over, with great and sim­ple de­sign wiz­ards to cre­ate UIs on An­droid and with the in­tro­duc­tion of sim­pler pro­gram­ming lan­guages like Swift on iOS, it is now quick and easy to cre­ate iOS and An­droid na­tive apps.

The chal­lenge of apps flood­ing mo­bile de­vices: De­vel­op­ers have started cre­at­ing sep­a­rate An­droid and iOS mo­bile ap­pli­ca­tions for ev­ery small func­tion and are in­duc­ing end users to in­stall many of them. This is now cre­at­ing a prob­lem with users’ mo­bile de­vices get­ting flooded with too many ap­pli­ca­tions.

The fu­ture: Bot plat­forms and spe­cialised mo­bile apps

To­day, most mo­bile users are al­ways con­nected to so­cial mes­sen­ger chan­nels like What­sApp and Face­book Mes­sen­ger or to mo­bile OS spe­cific mes­sen­ger chan­nels like iMes­sage. This in­creas­ing user en­gage­ment with mes­sen­ger chan­nels has in­flu­enced mes­sen­ger app com­pa­nies like Face­book and Slack to in­no­vate and cre­ate bot plat­forms, which en­able com­pa­nies to cre­ate business-spe­cific chat-bots to con­nect with their end cus­tomers on so­cial mes­sen­ger chan­nels. Ap­ple’s iMes­sage and Google’s Allo are both ex­pected to have their bot plat­forms to help cre­ate chat-bots.

Bot plat­forms are al­low­ing com­pa­nies to mark their pres­ence on chan­nels where users are in­vest­ing most of their time. This in­creases their chances of business. Chat-bots ap­pear as nor­mal mes­sen­ger con­tacts to the end user in a mes­sen­ger list, and thus do away with the need to have sep­a­rate mo­bile apps for ev­ery small need. More­over, bot plat­forms are de­vice and plat­form neu­tral — for ex­am­ple, Face­book Mes­sen­ger runs on all de­vices, be it mo­bile phones or wear­ables, for both An­droid and iOS.

Bot plat­forms are new, and de­fi­cient in terms of fea­ture sup­port and built-in de­vice ca­pa­bil­ity. So, for the next few years, chat-bots are ex­pected to be used for ba­sic func­tions and needs in­stead of hav­ing sep­a­rate mo­bile apps. Na­tive An­droid and iOS mo­bile ap­pli­ca­tions are ex­pected to serve spe­cialised needs/ re­quire­ments. As an ex­am­ple, it makes more sense to cre­ate high per­form­ing na­tive mo­bile bank­ing app for An­droid and iOS that lever­age a built-in fin­ger­print reader to au­tho­rise app ac­cess, or use a GPS re­ceiver to iden­tify the lo­ca­tion of a user’s mo­bile de­vice and the server list of nearby banks/ATMs.

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.