 I thought I introduced myself first, the Maditya, and the session is Dr. Droid Love, How I Learn to Stop Worrying and Love the Fragmentation. So just to disclaimer, I'm not Dr. Droid Love, though I do love my Droid more than, you know, I think we'll get into a discussion about iOS versus Droid later, but for those who are wondering what the title means, I thought I'd do a quick introduction. So it's inspired from the title of this movie. Many of you already may have gotten this, but I thought a quick review would be nice. So back in the 60s and 70s, there was this huge paranoia in the West about nuclear holocaust and war. And Peter Sellers and a group of other, you know, artists did this really funny parody of the entire situation and how stressed everybody was getting about, you know, the bombs and what would do to them. So it is an interesting parallel to the idea I wanted to convey about fragmentation. So we've heard a lot of, you know, fear, uncertainty and doubt about what fragmentation means to the Android world. We've heard about, you know, different developers putting out information about how they've had literally thousands of different devices, 90% of their support calls being about how people have complained that their app is not working on the device. And everybody sort of wonders when you get, especially as an app developer, when you get started, you wonder how bad is it, is my app going to crash the very first time somebody tries it? Is it only going to work on my Galaxy Nexus because, you know, what it's a Nexus device and I've tested on that and I've worked with it, what's going to happen? So I wanted to start out by sort of first laying the ground for, is it really fragmented and how bad is it and can we do anything about it? So is it really as bad as it seems? So briefly, we've all seen variations of this before. In the Android world, much unlike the way Apple does it, it takes a very, very long time for an OS to reach the majority of the population devices. So even today in 2012, you can see that the highest version is, highest coverage is by Gingerbread at 55% and the next is Ice Cream Sandwich at 3%. Which is alarming given that ICS came out a year ago and we've got Jelly Bean already and Jelly Bean is at 2%. So in terms of OS versions, it seems to take almost two years before an OS reaches a majority of users. And this is for a variety of reasons, not least of which is the multitude of vendors, the multitude of sort of carriers and how they push out updates, but we're not going to get into that. The next area in which we as developers face fragmentation as in we have to deal with is in screen sizes. So digging into our own applications, things that we've sort of launched two years ago now and overall we've now gained about a million installs. Back in 2011, you can see that a device with 480 by 800 screen had 55%. That number is almost the same now, but you can see that the change on the bottom of the rung has started to happen. Unfortunately for us, we can't rely on the statistics and say we're only going to build a app that works with the top number of screen resolution because today, the earlier adopters are the ones with the fancy phones, the Galaxy Nexus and the Nexus 4 for example. And if you want to survive in a country like India, which has a number of 3.2 inch screens like this Galaxy Duo or the Galaxy UI, we have to support a number of screens. And we've seen this a number of times before. Open signal maps, they put out a really interesting set of graphs and information about the devices they encountered when they released their app. And as you can see, this is the GT900, that's the most popular phone at the time when they release this information. And Samsung obviously dominates with the GT numbers that you can see. So obviously there are literally thousands upon thousands of devices out there, each with a variation in hardware from their memory on board, GPS unit on board, the processor on board, the kind of batteries that they have, a whole set of variations that we as developer have to deal with. So there are a number of other areas in which the device may be fragmented. But I wanted to focus on these three because as a developer that's what we have to encounter when we have to fix bugs, when we have to make an app compatible with a particular device or a particular kind of device. And there's one that I haven't mentioned particularly, but that is WebKit fragmentation, that sort of comes under the OS version. So the idea now is, we've seen the issues, the stress that one has to deal with in terms of what are the areas in which we are fragmented. But I wanted to present the idea that things aren't as bad as they seem. Google, if we follow the practices that they've laid out, the techniques that they made available and the tools they made available, it is actually quite possible to put out apps that cover all of these bases. It is astonishingly, at this point we've sort of built an app that is available in the App Store that we've had to do from the tablet to the small 3.7 inch phones in terms of form factors and it's not been as bad as I thought it was. So getting into one little piece is that learning to love it, we're going to have to follow these practices primarily because of this graph. Android has that about 68% and in a place like India, I think if you go into all the number of people who have an Android device versus a Blackberry and iPhone, I see a lot more androids than I do any other device. And when you see Android, if you want to get an app out to Indian users, you have to build for small screens. Micro Max has a device at 10,000 rupees at 4 inch screen. Carbon has a device at even lower with a really small screen. So we've got a huge plethora of devices coming and we have to be prepared for it. So the first of those three big issues, I'm going to take up is the screen. I believe that 80% of the apps we build are going to have this as their major issue, dealing with screen size because at some point or the other, there might be location based app or there might be an audio app but the number of times that you're going to have a problem with one of those areas is less than the screen. The screen is the number one issue you have to deal with. It's the first thing that a user encounters. The first thing, if they can't even see the screen you laid out for them correctly, if they can't see a button or if they can't click it or there is some sort of a UX error with the form, that's what they encounter first. So thinking about this from a, how do we start from the design level itself? We have to think about the phone and the tablets as two separate form factors and we think of them as 10-inch devices, 7-inch devices as 4-inch, 4.7-inch devices or 3.7-inch devices but Google looks at them differently from a developer, for a developer. They have grouped them in these classes which they call normal, large, and extra large and that's how we should deal with them as well. An extra large device is anything that has a screen size that stretches from a 7-inch to a 10-inch and normal being anything from a, on the border of 3 to 4.7 to 5-inch and the galaxy note that fits in the large, it's one of the few that fit into that category. So whenever we start, even at the design level, we have to group them at a normal and extra large. Think of them as form factors, the form factor and the tablet form factor and design for that. So the other element here is, we talked about a 400 pixel by 480 pixel screen, that screen can fit in either a 3.7-inch size or a 4-inch size or a 4.3-inch size which has been the case. So the other element there is the device density, Apple likes to call it their retina display in a 320 PPI display, the highest resolution but if you've got a much higher resolution available on Android devices as well. So as users, they're going to see a grainy image or a grainy button and that's another element that you have to worry about. So the way Google has classified this is in MDPI, HDPI and XHDPI but as far as development is concerned, that's actually one of the easier things to deal with once we start thinking of them as form factors and I'm going to go into the next step of fragments. So the way Google would like us to work with different form factors is to break functionality into its various components and make it reusable across the different form factors. So an example here is on the tablet, you can see a little, you know, sliding cruise or left and right, this from an app and the element that's highlighted, that has been built as a single fragment. And that same fragment is reused on the phone in sort of a vertical form and the user can tab through it left and right whereas on the tablet, it's available on a single screen just one below the other as a scrollable element. What this allows us to do is to sort of encapsulate both functionality and user behavior into one element that can be plugged into place just by setting a layout and that makes it very, very easy for us to go from a tablet to a phone. What is actually happening behind the scenes here is a single activity is driving both these UI. There isn't one single Java file, no two activities, it's just one Java file, two elements, one fragment and the same fragment is being reused. So how does this become, you know, something that is easy for us to develop with? So if you look at Eclipse, Eclipse has a number of tools available to us, not least of which is ADT which is a graphical editor for the layout. So I've got a few examples here that I'll show variation first. So what you're seeing is a profile screen for a user from the app, app lover and the same screen presented for the Nexus one and the Galaxy Nexus. So as you can see the variation in what the user will see on their screen and this is primarily because of the density difference, the difference in the screen size and the number of pixels available but this is one single layout, one single layout XML and it's all been done using the graphical editor ADT. It's got all the tools built in, you can see it in the top toolbar, the device selector, the landscape portrait selector, the layout, you can see the layout category is layout normal which is the device class that's available and you can see a number of other API level selectors. Another thing I'd like to point out here is you see a little blue highlight sort of surrounds the tick mark and there's a green line running through, I don't know if it's very visible on the screen but that's sort of the guide that is available via the graphical editor that lets you set up constraints and relationships that allows you to say that this particular icon should always sit in the center of the screen, not to the left, not to the right and you can see how that changes between devices and this is the same screen in a tablet form factor, same layout just a different form factor and finally, right so you can see what has happened to the same tick box, it's still centered within this fragment with the text so and all of this is being driven by a single activity so what I'd like to point out here is that we can develop using these three techniques fragments, layouts and the relative layer, I'll get into the details of this, we can fit in any number of screen sizes using these three techniques and given the time that we have, we have a 30 minute session, I'm not going to dive into the details of it but if anybody were to go in and start an app, start in this order, start by looking at the form factors you have to support, start by looking at how you would sort of divide the layouts and work with fragments and relative layouts, now what is the importance of relative layout, it's essentially the point that it supports the web box model, websites have been dealing with the issue of various screen sizes for ages, you've had browsers running on old desktops in people's homes which are you know, Pentium right up through with screens of 800 by 600, right up through you know, high resolution devices which are you know HD ready with 1900 pixels on one side and 1000 pixels on the other so and people run their browsers in full screen and you know, minimize modes so the web is able to do that because of the box model where each element is a box, it has a relationship with its sibling element or its parent element and it has a certain margin and padding so the qualities that the web has have been sort of brought into the Android framework and extended further, one of the things that we can do with Android that you cannot do with the web for example is this here and I don't know how clearly you can see it but it says align parent bottom true, that means it's buttons always going to sit aligned with the bottom of the screen so whether this keyboard comes up, whether the user moves the phone into landscape or portrait or the screen is rendered on a galaxy nexus or it's rendered on a tablet regardless of that this button is going to show up aligned to the bottom of that screen, the next element that gives it a position is the margin and you can see it says 71 dp 71 dp because you want it to be and for those who don't know what dp is dp is device independent pixels, this goes back to the resolution for think of it as pixels it's going to sit 71 pixels up the bottom but the difference between pixels and dp is dps give you physical distance almost like inches right the framework takes care of translating a dp into pixels on its own so on a high density device 71 dp might be something like 150 pixels but on a low density device that 71 dp would be 50 pixels but the fact remains that it'll always be saved quarter of an inch off the bottom of the screen that's what it guarantees you so if you use a combination of these three things relationships device independent pixels and the relative layouting of wrap content and fill parent which is on the top where for example you can see that I have a large screen and if I want a particular background to fill the whole screen regardless of what the screen size is we use fill parent the background will always fill its parent it'll stretch to fit now this is sort of at a high level covers all the elements of screen sizes the next piece that we need to cover off was or support an API level so Android has had about 17 API levels released so far the most popular right now obviously is the gingerbread which comes in at night and most users will have a gingerbread device but the best framework elements now come with ICS or honeycomb which is the fragment support so how do you build an app that takes advantage of the latest API is in the latest framework but still has to work on gingerbread for example so Google have made this really easy for us by making available a library which they call the support library what this allows us to do is to target our build to the highest API level that we desire so for example in our app we targeted the ICS API which is 14 and above and the reason we did that was we need we wanted to use all the APIs that are that come with fragments that come with with for example the tab bar handling or the action by handling and how did we support that on gingerbread essentially by including the library and making an import statement on every activity that we had and by doing this we were able to support fragments in gingerbread and the way Google have built this is that you can use this way back to API for which is cupcake 1.6 so support library is a great way for us to sort of forget about worrying about what is API is available what API is not available make the support library a part of your project include it in every activity and start using the API via the support library and an API level that was only exclusive to ICS now becomes available to gingerbread and this has sort of taken away a lot of the pain of having to support something like gingerbread now we didn't have to think about the API is available we just had to think about the screen sizes and hardware support there are a lot of instances where the hardware that the phone is running makes a lot of difference so I talked about supporting the OS and supporting the API level and that gives us for example access to fragments but that still doesn't mean that everything works smoothly I'll give you a number of examples the Droid Bionic is a 4.3 inch device it's got a high-density screen and it's been released by Motorola not more than a year ago or roughly a year and a half and you'll find that it continuously keeps crashing because it runs out of memory on an app that has heavy graphics and the reason is Motorola's particular flavor of gingerbread has set the heap size to such small level that the app keeps hitting its limit and and it crashes the OS kills the app this doesn't happen on a Droid incredible for example release at the same time as a smaller screen has a lower density screen but just the flavor that HCC made available of gingerbread on that device allows you to use it without any hitches so how do you how do we you know work around these kind of issues so the top tips that we learned were we have to pick three or four devices that cover the variety that we will see in the field right so pick a low-end device with a small screen bad hardware specs pick one on the other end a high-end device with the best specs which is going to be your hero device and the device in between obviously all factors from factors have to be covered so pick a tablet pick something like a Nexus Galaxy Nexus and a Droid incredible or Droid Bionic and test the app on each one of these every iteration has to go through a full testing cycle on these you'll discover a number of issues and if it passes the test on these devices you can be rest assured that 80% of your use cases are covered another sort of element to keep in mind is sometimes the app that we build is sort of specific to a particular use case a particular group of people and it's good to look up the statistics in that environment and see which of the devices they're going to be using so if we're building an app for India it actually doesn't make sense to spend too much time worrying about the Galaxy Nexus because the number of users with that device is going to be much lower so you might have it in your testing matrix but you need to spend more time fixing the issues that come up on the low-end devices say a 3.2 inch device finally you get a number of other hardware components that we have to deal with 20% case example location-based apps now we had an example that we built ourselves a while back which relies on location the what the app did was it looked up the user's address for roadside assistance and we built the app in such a way that you know you land on the screen it makes a query to the GPS subsystem gets it lat-long code it to get an address and presents it to the user and that worked great in our testing work great in the testing with most of the users we had in our beta test group except in the field it kept breaking we kept getting complaints that GPS keeps failing and what we realized was that for number of devices out there example the HTC hero user was not getting any result because the GPS lookup was timing up it was taking a lot longer than two minutes to get a GPS lock which was just snappy on a phone like the HTC incredible the droid didn't work on the hero so what did we have to do we actually had to apply a new UX treatment that allowed the user to compensate or work around the issue of not getting a GPS lock so what did we do we had to provide a little meter on the bottom that told the user as soon as the lock we gave them some information but we also told that this is not a great location we sorry great accuracy this is a very rough estimate and you wait a lot while longer before you get a really good fix on it so sometimes we can't fix an issue to for it to work perfectly on every device but what we can do is provide the user a mechanism via the interface that they can work around the problem they can manually enter the text for example of the address that they have or they can sort of wait and get you have a better idea of what's going on so they can work around the problem so these are a couple of examples of how we can deal with device fragmentation but I think I'm also running out of time but the last message I want to leave here is that fragmentation is an issue but it can be dealt with and I've tried to cover in the short time the three main areas in which you have problems and the techniques Google have made available for us to deal with it especially around screens and OS versions and API levels device fragmentation in terms of models and hardware there is no choice but to test and fix but we have UX worker ads so with that I'll sort of close and go into Q&A anybody has any questions you know happy to answer them yeah is there any facility by which we can you know test an app on different devices for different form factors I'm sorry is there any site or something where you know we can upload our app and get it tested on various form factors various devices all right okay so there are a number of sites are known actually tested for you but they offer you a remote device for you to test so there's a device anywhere.com and perfecto mobile these are two places that you can go to they hire out devices by essentially time slots you can reserve time on those devices and test your app that's actually a great way of testing sort of obscure devices that you have a particular issue on that you know for example you don't want to go out and buy the device but it's highly recommended for your top three devices especially if you're serious about the app you know I can understand as an indie developer you may not want to go out three devices each which might cost you 20,000 rupees that's a lot of money to spend just to get an app out there so you can use these services though if you're sort of serious about the app then I recommend getting buying three devices and testing the rest of them on a remote service like device anywhere yeah yeah the question was related to the OS versions is this the one? I assume when I was developing the app I was targeting ICS and then Jelly Bean came out and Google fixed something like that there was a bug in fragments and Google fixed it in Jelly Bean so by essentially using this library I'm forcing even Jelly Bean or ICS devices to use the library implementation that's true in a way because it will be coming from the library but that's not exactly what happens so two things Google A keeps the library updated with every release of the API so they do when they release Jelly Bean they revise the support library number one but the library is included within the app right I'm bundling the library within my app so correct will it get automatically updated that's true so you will have so for example the so the library also does another thing right it is a native implementation available for that particular feature and obviously falls back to that but in the case of say I mean when you talk about a fragment having an issue right you're talking about the fragment that issue showing up in gingerbread as well and if they fix that there's you cannot fix it without updating the library or fix it for the gingerbread device without updating your app itself I just wanted to confirm if I mean so some of my users will still be using gingerbread so obviously for them I'll need to update the library and push out an update right but wouldn't it be awesome if the users who are using gingerbread are using Jelly Bean or ICS automatically get that fixed functionality because the library falls back to the native implementation so when it's available for example on ICS or Jelly Bean right so if you're using the the action bar for example it's a native native version of the action bar that becomes available is presented to the user with your customizations obviously over it thanks hi in the in the case of full-screen applications till gingerbread the handsets are coming up with hard menu keys right but after that they moved to the soft keys where in which exact menu key was missing where in which they moved to action bar right so how you have handled that kind of applications it's actually we don't have to do much for that so for example if your apps already been built and you designed it for the gingerbread phones and you included you know the action action menu items where you had you know you click the little menu button and it brought up the prompt those will continue to work in an ICS device you'll see that on your phone for example when there's a little three dots next to the the back button or not the back button sorry the the task manager button on an ICS device for example on a Honeycomb device so that menu is still available to users where the app is targeted the gingerbread and made available in ICS that button is still available but if you're redesigning your app then it's suggested that you get do away with that menu system and use the action bar where possible and include those same options within the screen itself if you can because that then that design pattern has been done away with by Google they don't want you to use it thank you hello yeah so what happens normally is I end up writing a lot of if else conditions you know to handle different device if it is related to hardware you know most of the times I end up writing in custom use a lot of if else conditions so is there a technique to avoid that so you were mentioning about the GPS example you see most of this with the hardware so what's the normal yeah actually I would I mean if as far as possible we all want to avoid the if else condition so that's why I said a different UX treatment is useful for example we could have written code in that app that said if hero do this right if hero wait for five minutes I'm not I'm not talking about a specific device man I'm talking about specific hardware availability or not available right so in that case again one should sort of if if the GPS subsystem itself is unavailable right then the UI has to make that sort of adjustment so you need to check if course permission available versus if fine permission available right if fine grain GPS is not available then you obviously your app cannot use that ability so those sort of conditional statements I think are fine because they're their capability based they're not device space so it'll work the same way in an axis as it does in a droid because they have the ability but those devices that don't the UI will fall back you will have to write obviously a design which will fall back to a form field for the user to enter text if it doesn't have a GPS subsystem for example does that make sense yeah okay hello droid love wanted to understand you talk about you know how you learned to stop worrying about the fragmentation because of all of these work around right but I still want to understand why do you love fragmentation I love the Android device and you have to learn to love it because if unless you learn to love it you're gonna be stuck worrying about it right so that's the whole the idea of the parody that if you keep worrying about it you're gonna live in fear learn to love it and you'll get over it sure hi yeah hi hi this is I said so I am completely aware about the fragmentation part and I like designing for the fragment areas right but I am I'm little confused with what if it's a custom view like like a class extends linear layout or a class extends relative layout and everything is custom custom based where DP and SP doesn't work there is there any inputs that you could give me so I would say if you extending something a gradually out in your and it doesn't support DP then it's a bad idea no obviously you can't implement DP in that but like to position the elements in in that layout right like if I'm breaking out of norms obviously following the design patterns and breaking like bringing a custom view inside a actual view that is there and if I want to if I want the widgets to be consistent in all the form factors of the devices is there any inputs that you can yeah I mean I can only give you an example that's something that we've already done this is completely custom what you see on the top it's something like the pulse UI where you have a carousel that slides left and right most of the standard controls are you know this slide up vertically but this is a horizontal scroll with all the elements laid out one below they were just very similar to pulse so you can browse vertically across different carousels and left and right in a given carousel right so this isn't a standard UX treatment that Google makes available so it's built custom and it's built on top of core elements but everything that we build is an extension of a core UI widget for example this is built on view it's an extension of the list view using an adapter and we've had to handle the rendering on our own but the rendering always respects device independent pixels and it respects all those variations that you can have in terms of the you know relative layouting etc so at its basic level it's using all those core components it's using relationships across various elements it's using device independent pixels and it's using fragments so any number of custom layouts can be built using the core fragments you just have to extend it in a way that respects those basic behaviors that will allow for it to work across devices so that's carousel menu yeah cool thanks all right thank you I think we run out of time but thank you