Droidcon Montreal – Ty Smith – Building the Fabric SDK

everyone i’m ty smith i work at Twitter last 2013 we started a project Twitter to bring all of the SDKs that we had under one roof an umbrella product for our developers we call that project fabric and today I’m going to be giving you guys some tips and tricks on what we learned from building that and then how you can use those to build your own SDKs libraries or even make better applications so what is fabric exactly well it’s a set of modular SDKs that share a common platform so we have a reduced footprint and adaptive for developers for an application that a developer may use the Sun we released it last year in the fall and best of all it’s free for everyone to use we believe it’s a great way to bootstrap your mobile apps as we were building fabric we kept several goals in mind that helped guide us as developers we think that these ideals are they’re great to use for your own applications or any sdk that you’re going to be using as well so I’ll walk you through those today we currently offer 7sd case that are all makeup fabric these we call these kits they’re logically grouped artifacts that we distribute it can be one or more artifact and we on Android we bundle these as a ARS the crashlytics team had a huge influence on fabric as we were building it out and so that’s a large part of what we offer as well the kits that we launched with include crash reporting analytics beta distribution sign in with twitter embedded tweets sign up with your phone number which is white labeled and our advertising exchange fabric is much more than just a set of SDKs though it’s also it deeply integrates into your development flow we integrate with all major IDEs and on iOS 4.x code and we also integrate into the build tools like ant maven and Gradle so you can quickly on board new applications inject code needed to get started really quickly provision your app keys and then provide dashboard functionality for your SDKs part of our platform is providing a consistent back-end experience we offer dashboards for all of our products so we can monitor and interact directly with the SDK here’s an example using our answer circuit which is our analytic service so we can observe stability over time for an application help get app developers started with fabric we created an open-source to game that we call cannonball it’s a social magnetic poetry game you guys can get this on the Play Store today and you can also check out the source code at github com / twitter deaf perfect now that you have an idea of what we’ve been building for you let’s talk through the learnings that we had from fabric and talk about how you can apply those so before we start showing code we need to think about some considerations that you want to think about before you start building a library or an SDK first is what need are you actually serving here are you building this for your internal developers for another team at your company or is this for public developers who’s going to be using this and what value are you adding I think Jake and Jessi talked a lot earlier about don’t just build another JSON library I think this is really what I’m trying to get at here is really figure out the need your serving before you decide to move forward with this next is you need to think about how you deliver your project on Android there are really four major ways that you could deliver a product for an app developer to consume the first is a standalone library project this is the oldest in kind of the most straightforward solution it involves just having your source code available on github or elsewhere and the app developer checking that out directly into their project marking it as a library project and Android studio or in Eclipse and using that but it has a lot of problems as well how does an app developer stay up on your updates what if they forked and cause problems how would you know is the SDK developer what’s going on here the next our jars which are a great option you know they’re really old come from the Java world pretty standard however in android you’d be limited in that you can’t have views in your jars so if you’re doing any sort of view related library that could be problematic ap Caleb’s were kind of a community introduced solution to this project when maven was starting to come out as a big build tool for Android and it is just a zipped up version of a library project I wouldn’t necessarily recommend using this because it’s not the standard approach ARS pretty much replaced this and you’re not going to get great support in the tooling going for it that brings us to a ARS which are the current recommended approach by google it’s a zipped up it’s a zip container that includes the compiled class files as well as the resources you can use this for view related libraries or anything else one of the downsides to a ours is that currently eclipse doesn’t support it yet the fabric team though we chose to use a ARS regardless of the Eclipse support and our tooling that I talked about earlier actually handles this for the user we we have our our plug-in that uses IV internally to resolve to our maven repository pulls

down VAR unzips it and then injects it into the workspace as a library project this is a little over a lot of overhead but as the android community moves forward eclipse will be less of an issue i think another consideration you need to make when you’re building an SDK or library is it doesn’t necessarily have to be open sourced although most people would prefer it would be and I I love open source but you also need to consider that you have may have business requirements that lead you to a close source solution and what does the associated licensing that you need to consider if you are open sourcing it some things that you might consider for keeping a close source library or what sort of back-end requirements do you have where is the value in your product is is it an sdk for business logic or is it an sdk just as a utility when you’re talking about licensing a lot of people need to be wary of GPL license this a more flexible license that i’d recommend is either MIT or Apache to this is something that you’d probably especially if you’re in a bigger company you need to talk out with your legal department the last consideration you need to make is where you’re going to be hosting these artifacts if you’re open source the library then it’s great you can put it on maven central or Jason ER and most of the standard tooling resolves this out of the box but if you’re having a closed source sdk then you can’t put it on maven central or IntelliJ so the users going to have to put a custom maven repository in the build script so that’s something extra that you’ll have to communicate to the users of your library all right you figured out your product strategy let’s talk about the two qualities that we really focus on and for fabric and that’s being powerful in lightweight the first goal we aimed at with building a powerful sdk to some of to us some of the things that make an sdk powerful are its ease of integrating the sdk into an applique the extensibility of the API handling failure gracefully and runtime detection for flexibility would anyone sets up to build something they don’t even even if it’s for own consumption they don’t think to themselves that they want to make it complicated it just usually happens over time they didn’t try to have a constructor that took 15 parameters and zero documentation or the opposite 10 pages of documentation that takes forever to read and is extremely verbose and hard to understand but these sort of things happen and it makes using SDKs or open-source lights part open source libraries or even parts of your own application really hard to use so our first goal with fabric was to create an SDK that was pretty easy to use we wanted to create the easiest way possible for developers to get started and it doesn’t get a lot easier than this we just use one line to initialize fabric and get started but we require different dependencies right and so one example is that we require an API key with fabric so that it can interact with our back-end service and be provisioned appropriately so because we have there we go that’s much louder thanks guys I’ll just start over so we have a back-end service for fabric that’s a big part of the offering and we needed an API key so that we can provision and we can have you know detect unique users and accounts and everything else but we didn’t necessarily want to require this API key be injected at the very beginning by the developer and add that extra overhead so we try to detect the dependencies winning when we can we use our our plugins and our onboarding tools to inject the the API key into the manifest where we can use the context to resolve that at the beginning of the initialization with fabric we do also by the way if you have an open source library and you don’t want to include your API key we do have some alternate approaches like it can be through a properties file that way you could add that to your get ignore it’s trying to be a little bit flexible but once we’ve started this initialization process we can use the package manager we can read the manifest we can grab that API key out and then we’ll be good to go to start making our network requests as you can see in the initialization process of fabric it only captures the application context this is important because if we were capturing the activity and holding on to that in a static instance fabric is stateful it was statically across your entire application if we were holding on to that activity we could potentially cause memory leaks so we’re holding on to the application context and when we do use the activity context we reference it to avoid the sort of memory leaks this is another example of getting dependencies when we need them but but taking a little bit of flexibility so a part of fabric is the Twitter API client it’s the client you can use to make authenticated requests to the Twitter endpoints you can do things like embed tweets or you can just create content on the Twitter back in service so what do we do here we take an authenticated session as a constructor so that you can manage multiple sessions yourself you could have flexibility for multiple accounts but in the event that you don’t want to manage that yourself our empty constructor goes after our session manager and we try to get the active

session from that so this is a great piece this shows the flexibility that we provide we’re in one case it’s a building block for developers they can use it very explicitly and in another case for someone who just wants to get up and be using it a little bit quicker we provide the session management under the hood for them hopefully some of you will say hey why don’t you use a dependency injection framework this would simplify the sort of thing a lot and I would say I would love to and we use do use dependency injection as a design pattern but using a framework like dagger becomes problematic when you’re writing SDKs and libraries because it adds extra overhead and it kind of goes against the second quality we’re going to be talking about later which is being lightweight another thing that’s really important to us is that our SDK is really modular and extensible I was happy that Jake and Jessi called this out a little bit earlier it’s it’s super important so when we introduce the concepts of kits or these functional units that developers can add only one piece and they don’t necessarily need to add the entire set of fabric which would be a lot of overhead but once they had these small pieces and we needed them to be very extensible so they could easily update and add new features you know even with the api client we don’t provide all of the API endpoints by having an extensible API we allow the developers to use the authenticated logic that we have and scale that out pretty simply and I’ll dive into that a little bit more in a minute existing users of crashlytics you guys will recognize this first line and if you were a power user you might recognize the other three lines we had these these extra setters and they were all added over time and by different people in different styles and just at a first glance you can tell that there wasn’t a lot of consistency with with the style that we were going after here these are things like adding you know custom SSL pen or or setting a listener for when a crash happen you can do some simple stuff like that which is powerful and needed but when you’re looking at this it really wouldn’t be clear to you when like you need it to set the stuff up before crashlytics ran and because crashlytics is installing an uncaught exception handler you don’t know when it’s ready to use so unless you really read the Javadoc you wouldn’t be clear on the proper uses of these they’re actually supposed to be called before crashlytics has started so that when it starts making its first Network requests and setting up the the uncontacted handler it has that information ready to go so when we started building out fabric we tried to make this better if we needed these parameters to be called before start why didn’t we just add them to our initialization call and then as we add more functionality we can keep tacking on parameters everyone loves passing around a series of nulls or you know meanings meaningless integers we thought there had to be a better way and so what do we do we decided to utilize the Builder pattern where you can specify additional optional parameters for each kit but this pattern helps alleviate the burden of having these methods or constructors with too many inputs so what we do here is we we take all the optional parameters and we guarantee when we construct the object that it’s in an immutable state so that their thread safe and that we have all the defaults that we need we also made use of this builder pattern and fabric itself so we allowed the developer to set all kinds of complex you know additional settings on fabric they wanted to set their own blogger we add that if the want to set their own custom executor service if they want to turn on debugger mode we allow all that through the Builder pattern as well part of making extensible code its long to developer to choose to be notified when certain behavior happens so here’s an example of initializing fabric with a listener for when the initialization is done we do both synchronous and asynchronous initialization with fabric and all of the kits and for some developers it’s important to know when everything is completed so that they can continue and so by using the Builder on the previous screen a developer can set this initialization call back and then they can be notified when this is done developers have quite a range of tools and therefore they need a lot of flexibility in their code we provide extensible interfaces to try to help with this one example is logging like Jake called out earlier there are many different logging frameworks they handle different things in all kinds of different ways and a lot of them try to have cross compatibility with other logging interfaces what we do is we provide just one simple interface and then a default implementation of this interface so if you were using something like timber or log4j or whatever logging interface you wanted to use instead of logcat you could quickly implement your own version of this interface and call through to your own lager and hand this to fabric and then we would respect this through the entire set of the SDK logs here’s an implementation of our default when that isn’t passed him by the developer we just default to lock at which we believe is the same default using the Android lager another great example from fabric is the API client

that I called out earlier we have some of our most popular Twitter and points to find already in fabric but there’s if you’ve ever worked on any Twitter products and looked at the rest api documentation there’s hundreds of endpoints most of them are never used you wouldn’t need to use them except for very specific use cases and we didn’t want to maintain an sdk with hundreds of unused methods so we chose only to provide the most popular ones and but then we made our API client extensible so that a developer can extend it create their own custom API client and then provide their own retrofit style interfaces to hit the endpoint that they need more than just code though we believe its extent that it’s it’s good practice for extensibility to apply to views as well so what we do here is we allow our embedded to our embedded tweets or login button different UI elements that we provide through our SDK to be themed able you see you can do this through styles one important thing to note though is that Dex merging doesn’t namespace for libraries so you can have conflicts you could have unintentional overrides where you defined something that was very generic like maybe you had a button in its background color was just colored background developer in their application probably has something to find his background as well they’re going to override you unintentionally so we namespace everything so that we don’t have these unintentional overrides and if the developer does want to intentionally theme it they can define the namespace that matches ours aside from implementation details that we just talked about when designing your API we generally think about a few traits the first is being intuitive an API should act the way the developer expects without having to reference the documentation your SDK should be consistent especially the naming so name your methods in a similar fashion across your entire library SDK application whatever use common language don’t name the success method for Network callback success and success for a database operation on success an API should be easy to use and hard to misuse validate your inputs have seen defaults make the developer feel safe and feel like they have an understanding of what’s going on just by looking at the code without documentation let’s talk about handling failure because developers are are impatient and inquisitive and the faster something fails the better and I’m sure if you’ve been using Gradle you’ll know what I’m talking about after it’s been building for five minutes and then fails and you feel like you have wasted time you should throw expected exceptions when the developed so that the developer knows there’s a problem quickly and it can be addressed when it’s appropriate so you wouldn’t want to fail in production this this sort of failure needs to happened during the development cycle so that they know immediately they lacked a dependency they threw pastor Nolan it can be addressed but you should really try to catch all exceptions and only do that intentionally in development mode they’re at a developer’s app is often their livelihood and so if you’re an SDK that’s crashing they’re not going to buy tonight replacing you with something that is a little more stable so i’d recommend gracefully degrading if that’s the case so if you’re in production here’s an example where the api key was in all the developer shipped fabric out without it unfortunate fabric can’t run but we don’t want to block all of their users from using that functionality since fabric is secondary functionality for them most of the time so if we’re not in a debuggable state then we’re just going to return null we won’t start fabric up that’s unfortunate but it’s not the end of the world the users still get a good user experience your SDK usually doesn’t have the same luxuries as an application you don’t get to really pick and choose your devices you don’t get to choose your API levels or your customers so as an sdk developer you need to provide maximum flexibility so the developer never has to make trade-offs when deciding on your library versus a competitor you ever checked out a library or a an app in google play and thought to yourself why does this flashlight app need to modify the contents of my USB storage permissions are powerful and they allow you to integrate deeply in the OS but they can seem really scary the users who don’t understand what’s going on with them or how you’re using them and if they’re added after the first launch of your application it can break auto updates as well causing a really long tail for that next update cycle in general apps libraries especially should limit the number of permissions they require fabric requires just the internet permission and we then provide hook so the developer can set extra information they may have collected by using other permissions but we don’t require it so our SDK wanted to capture the user’s email we need to have a script Gary permission like get accounts your application would have to declare and your users might be concerned about since they don’t know what what’s actually going on with this thing so we provide the hook like I mentioned earlier set user email so the developer

can require the permission if it’s at that important to them and and set this on crashlytics and it will be available to see in the web dashboard so with that in mind though the developer can set different permissions and you can have better functionality if that permission exists without requiring it by using permission detection here’s an example where we’re not going to upload crashes to our back-end if we don’t have network state but network state roquat requires the permission for access network state and so we’ll check that using the the context and if we get a success back then we can go ahead and we know that we we know what the network state is we know if it’s connected or not and we can go ahead and perform the upload but since that permission is optional we need to have a standard default for this and that is we always try to upload if the permission isn’t available because we wouldn’t know otherwise and we’ll get a will just get that error in the network stack instead like permissions though features are another powerful aspect of Android manifests if you were building a camera app you might be tempted to define the feature for camera and and not not see that there’s a required flag that’s optional if you do that then Google Play filters this app on devices that just have cameras what if you had a tablet with no camera and this was a social with no hardware and your app was a social camera app like Instagram where you could browse photos you could upload them instead you should add this flag and you can specify that it’s not required and then in your code you can detect if the camera actually exists and if it does you can allow them to that functionality to access the camera if not you can block that out in the UI and not let them get to that part another important part of runtime detection is being able to figure out what version of Android you’re running on this is probably common sense for most of you but you know things like builder hardware wasn’t available before Froyo and so if i had an SDK or a library or an application that was calling this and it didn’t get caught this could cause a runtime error if it launched on a device prior to that detecting something like speech detection is a little bit harder it doesn’t require a specific Android version or a piece of hardware it requires an a service that’s running on the device so there’s a couple approaches to solving that one is you can just try to start an activity with that with that service in mind and then if the activity is not found there’s an exception thrown you know that you you don’t have that a more elegant approach I prefer is to use the package manager to query for activities that would support this action and then if your activity list is greater than zero you know you have something on the device that can handle speech detection and you can safely move forward when providing SDKs to your developers it’s really tempting to use awesome new libraries like ok HTTP or RX Java but you really don’t want to add third party dependencies in lightweight libraries I’ll talk about that a little bit later but in this example what what we do is we want to use ok HTTP it’s a it’s a great networking stack if it exists and developers want us to be using ok HTTP when we make all the requests to the Twitter and points of the crash so they can points so what we do is we use the provided scope and Gradle or if you’re using maven you can use the optional flag and then we have methods that does that we do runtime detection looking for the classpath if that exists then we know that ok HTTP exists the developer has defined it as compile we’ve just provided it we’ve just defined it as provided so it actually requires the consumer of your SDK to specify compile but they may be using it for another reason already and we’re just trying to piggyback on their choice to use it and so then here’s an example in the Twitter API client if we have ok HTTP on the classpath then we can go ahead and use the ok HTTP client for all connections and if we don’t we can fall back safely to the URL connection client which is just an implementation of androids URL connection it’s important the developers that include your SDK can use it with their standard testing tools they don’t want your SDK making network requests every time a unit test is run and you probably don’t either your back-end engineers aren’t going to be your friend if that’s the case and so you really want to make sure that that your functionality is tested that they can test it in writing unit tests and mock those sort of things there’s some tricks to making your SDKs testable and really I mostly mean mockable in this case a lot classes just a dummy class that represents and has no ops for the method calls and allows for various types of validations and you can specify return types from these methods so that you can test them appropriately and with that in mind I think that it’s really important to avoid static methods in helping with with mocking and testing it since

mocking happens on the instance variable or in the instance method the static methods are going to get their their default behavior and so that’s not accessible if you’re going to be using static methods they need to be tested in isolation and make sure that your dependencies can be provided upfront many mocking libraries have problems with final classes so I’d recommend avoiding those as well mockito is a prime example that doesn’t like final classes I think power mach can handle them but it’s kind of hit or miss public fields also aren’t accessible on your mocked classes so everything should be running through an accessor utilize interfaces as much as possible around your public api’s it’s much easier to set up classes to test if your entry points use interfaces they’d allow a developer to override behavior quickly and set up mock servers or in memory stores instead of real expensive operations that could potentially be inconsistent lastly avoid mocking more than one level deep it gets pretty challenging to set up unit tests if you have to provide a mock object and then say when I asked for this sort certain behavior provide another mock object and when it acts it needs another mock object if you’ve ever tried to do any mocking around context and resources and Android you’ll know what I’m talking about here so this class represents some of the things that I just talked about that I think make it a little harder to test its final it’s a singleton it’s pretty common in Java though the singleton pattern it’s kind of an anti-pattern and it makes challenging it makes testing pretty challenging especially in isolation so what could we change to make this testable instead I recommend making it just an instance class and the developer can reuse or cash this when they need you’re not worrying about the single use if you remove the final modifier than mockito can safely mock this and also allow the the network to be passed in as well this allows the developer to mock the network so that you’re not actually hitting the real network and they can return the results that are needed dependency injection really isn’t just a framework like I talked about earlier it’s a design pattern by taking this sort of thing up front it helps you organize your code better around testing okay we talked a little bit about powerful SDKs the importance of ease of integration the extensibility of the API handling failure runtime detection and making it testable so next let’s talk about making an SDK lightweight during the building the frosting the the building process for fabric we learned a lot of things about this and these are really applicable to all apps libraries and SDKs so let’s let’s keep these in mind some of the things we’re talking about our binary size watching out for the Delphic dalvik method counts limiting network usage encouraging modularity and optimizing for startup time users are a lot less likely to download a big gap this means that the binary size matters a lot unlimited data plans have come in and out of fashion over time and many users around the world even pay per kilobyte this is especially true in emerging markets also in emerging markets many some much time much of the time the cell connectivity is too slow to download a large app so there’s some great third-party libraries out there that can really contribute a lot to your app but they aren’t free when it comes to the size and impact on your on the user’s application for crashlytics are crash reporting back end uses protobuf and protobuf for those who aren’t familiar is just a binary serialization protocol that creates small data objects for efficient transfer to the web service the java library for protobuf added over 700 k to our sdk which is significantly larger than the sdk is today we didn’t need all that functionality from the library so we decided to rewrite part of the part of it that we needed ourselves before the time of wire our nano or other lightweight protobuf libraries existed the original protobuf of 7 or k like i said and when we decided to just implement our piece of it we got it down to 10k in crashlytics so it was a it was a savings it was worth it even though it took a lot of time because we you know they’re just look at the numbers it’s obvious and when you’re when other app developers ered are making these sort of decisions with your library you wouldn’t want them to choose a competitor because yours is just too large there’s a really easy weight loss weight loss hack that focuses on data collection if you just weigh yourself every day you will lose weight you’ll start subconsciously monitoring what you’re consuming we take this approach to our SDKs as well we actively monitor the money to build and we report this and we can weigh the true impact against the developers apk and we can graph this over time there are no hard and fast rules around size increases but it’s generally helpful to know how specific who made increase the size of your library and investigate if that was with or without warrant as anyone in here run into the the dalvik

65k limit before a few of you and if this was you know before the time of multi decks it was a little more challenging to solve now you can for those of you who aren’t familiar with it it’s it’s a finite limit on the number of method in vacations allowed to be referenced by a single Dex file it surfaces when the deck still tries to write all the method references in a single spot in memory and there’s not enough allocated for it and it fails so now you can use multi decks and that’s great it works but it does seem to increase the first app launch when it loads into memory and it’s not really suitable for all users outside of the newest cradle users I think a lot of you if you ran into it before the time of multi texts you’re going to do what what a lot of people do and that’s you start looking at your use of third-party libraries and how you can start refactoring Andrey architecting your app to remove code bloat and this this sort of SDK audit is pretty common you don’t want your SDK to be pulled out of an app developers out of a developer’s application just because you were too large and they needed something news a little more modular in lean we use a great library that was written by an engineer at quip to track this on each build if you guys want that the github links up at the top it just allows quick insight into the size from a method count perspective of all the packages for both our SDK and our dependencies we like the the tracking of the sizes the binary size we also track this and graph it over time it’s just really helpful to have an insight and to where things are getting added minimizing network usage is is pretty important too it has the highest impact on battery one of the highest impacts on battery and I mentioned the data conscious reasons earlier about paying per kilobyte so we use proto buffs to help with this protobuf isn’t right for everyone it’s but they are exceptionally small because they don’t include the schema like something like JSON or XML over the wire with protobuf it’s all compiled down in a binary there’s an IDL that the sender and the receiver both agree upon and that allows for much faster transfer because it’s smaller and because it’s a agreed-upon IDL serialization is much faster as well so my advice is look into what your needs are for the bus not right for you thrift is another similar approach JSON compile JSON could work for you guys it just depends on the size of the data you need a transfer batching requests is is highly important when you’re dealing with the radio this has been talked about a lot so I’m not going to touch on it too quickly but if you guys are making the radio too frequently it’ll leave the radio and a high-powered State for the majority of the time it rarely gets into the low-power an idol if you are running it requests every 20 seconds or so you know a naive analytics SDK made just for port hey I’m in the foreground pretty frequently something like this could happen if you were to batch those requests every 20 seconds into one a minute you could get much more like the graph on the the right over there where you’re in the idol and low-power state much more frequently when we started fabric a huge concern for us was how we wouldn’t provide one giant SDK that had all the functionality that required that that everyone had to use and so we wanted to break this down and make it extremely modular so we we took an approach that used mavens dependency system so that we could have transit dependencies we wanted modularity and we want to developers to be able to just say you know new Twitter and have all that functionality but we broke that down by sub kits so that a developer who just wanted an embedded tweet or just wanted access to compose tweets without all the underlying functionality could also do that with fabric so this is a providing choice for the developers this diagram represents kind of how we architected fabric we have one base artifact which is the fabric aar it has common functionality like caching persistence interaction with our web back end at provisioning events management and other things then the next level up we have our arcade common services so if we’re talking about Twitter crashlytics this would be common code that the different feature sets shared could be things like a specific networking or authentication code for an API that we’re dealing with the next level is is more of the user features level so this is the set of features the developer wants to to utilize this could be things like crash reporting or analytics lastly we have an interface level to bundle all of the features together this allows for really simple onboarding for a developer who just wants to get started with with one line and have everything but because the stack is built top down he could choose he or she can choose to just use a specific kit and skip the kid interface all together let’s see how that works in practice here is the stack of Twitter functionality we have quite a few a hours that are being delivered if you use the onboarding plugin then you’re just going to get Twitter AAR and it has transitive dependencies all the way down to fabric but a developer could choose to use just tweet you I for example and then they would only get tweet you I

Twitter core in fabric which would be a much lighter weight solution and this is just back to to being back to providing choice for the developers how big are the fabric ARS we talked about because we’ve broken them up like this we can keep them pretty small we can keep a lot of the the bloat in fabric itself which is shared and then we have a lot of this functionality that’s split out they can be really lightweight and we can share a lot of things like the arcing currency system is in fabric for example that way we don’t we’re not spinning up threads for each SDK with fabric one of the goals was to reduce our startup time as much as possible since people are starting this at the beginning of their application launch and so we do things both synchronously and asynchronously and we try to get off of the main thread as fast as possible there are some things that need to happen on the main thread like installing the crash handler so that if you have a start-up crash you want to catch that you don’t want to be a user stuck in a bootloop so we we use a just executors and it’s important that if you are using these executors that you also set the background the priority to be background because if you set the default priority it’s going to be the same priority is on the UI thread and that can still cause jank I’d recommend if you guys are building your own SDKs you think about how you can get off of the main thread as quickly as possible to here’s an example of the the background priority that I just mentioned I’m going to skip forward a little bit since I’m running a little short on time I think so when we were talking about improving startup time in Patrick I mentioned that we have these shared resources things like our concurrency system that live in fabric all the SDKs share that so that we’re not running too many threads we also do the synchronous and asynchronous initialization that I talked about we it’s important for us that we had different priorities for initialization some kits needed to be initialized before other kits so we built this into our thread pool executor and lastly we needed a set of dependency so that we could guarantee that some things ran before others not just that they were higher priority or lower priority we built that in as well these are probably overkill for anything that you guys might be wanting to do for your own SDK or library but it’s important to think about the considerations that you need to make when having an impact on the user’s launch time so we talked about lightweight SDKs you know the binary size keeping an eye on the dalvik method count higher network usage counts how to be as modular as possible and how to curtail startup time there’s one other thing that we need to quickly talk about and that’s the support you’ve built a really great SDK it’s it can be used but if you just put it out there and that’s the end of it you’re not going to get a lot of adoption it’s important to think about how you can support your developer community this is saying I like an API is like a baby they’re fun to make but they take 18 years to support any API you add will require a lot of of maintenance I would think about how it affects your roadmap and your architecture choices have really clear and concise documentation this is one of the first points that developers go to learn how to use your SDK document every public method and expected use cases right concise and simple sample code people will copy and paste your sample code so much you don’t want to create a full gallery application just to show off a small image loading library you want to have it as simple as possible so the developer can go in they can see what’s going on and if they are going to be if they’re going to copy and paste it there’s the least chance for books inevitably you’re going to write your version one and it’s the first thing you’ve written and you think it’s amazing you put it out there and the internet hates you and your library and you you you go home and you cry and a couple weeks later yuri watch this presentation and you wipe away your tears and you start on version 2 so when this happens be nice to your developers don’t just rip out all the methods that you thought were poor design choice from the beginning deprecated market is deprecated set a clear road map for when that will actually be removed so the people that are using it no know what’s going to happen and then think really hard about introduction of new public methods because you’re going to have to maintain them for a while okay thanks for coming to learn about how we make lightweight and powerful SDKs I hope that you guys can take some of these tips and apply them to your own libraries or your applications even now I’m a little I’m available for questions for a couple of minutes yeah yep ok yeah so a ours it’s a it’s just a type

of artifact that can be included in a maven repo or an IV repo or Gradle repo you yeah so if you wanted to use embedded tweets for example you would define a dependency in your Gradle script which just says I depend on the embedded tweets and then the palm file that’s generated which is the metadata associated with the AAR that was in the maven repository describes what it’s transitive dependencies are and so then it knows that it depends on our Twitter core library and then that knows that it depends on our fabric library so for you as the developer you only ever have the one dependency in your build script which says embedded which says the tweet you I but under the hood it’s pulling down three libraries to make that happen yep yes the jobscheduler would really neither so that would be your business logic of how you’re using that with your networking stack so it would you would use ok HTTP to to make your network requests but it’s not scheduling when they’re going to happen right so if you were designing an analytics library for example you would need to have your own logic that applied the job scheduler or your own timing mechanism to upload those when it was appropriate yep in the back yes they will be i’ll post them after the talk yes sure um regardless follow semantic versioning so that you when you break your API and you know that you made poor decisions and you update it that that’s communicated clearly i would say the communication with your your users is extremely important so if that’s the case then talk about that be really reluctant to version that of 10 you know say i want to put this out there and I want to get feedback and then once I have that and this isn’t a little more stable state then I’ll you know consider doing a 10 that way people are aware it’s in the active development state and you’re experimenting and you are in that like fast velocity state but as to your point of like which priority which things to prioritize you know stability is extremely important if people get a bad taste in their mouth from your SDK when it’s even if it’s a 10 and then laid it you know two years later it’s a much later version and it’s completely different they’re going to think yeah I tried that a couple years ago and it crashed my app and then crashed a bunch of users I’m not going to look at that again so stability is pretty important yes just mobile developers an entire stack the fabric or get Twitter’s about 50 people now and so that that’s a lot of web engineers that’s infrastructure people that’s iOS engineers that’s Mac App engineers that’s Android developers that’s ide developers they’re split into feature teams so I work on primarily on the fabric platform piece and then I helped a lot of other teams build on top of the fabric aar and kind of work with architecture and do code reviews and those sort of things and so that’s that’s my piece and then there are teams that do just the the Twitter SDK is that built on top of it there’s a team that does just the mopub SDK and they crashed the different parts of the crash lytic SDKs and those are all distributed pretty evenly yep yes right now it’s under our twitter terms of service because they’re not open source so there hasn’t been a licensed chosen for that yet when you’re considering your own libraries if it’s open source like i said i’d recommend apache to just fall in line with what Google is doing on android MIT would work pretty well also I definitely talk to your legal group at your company or someone who has a little more knowledge on the legal ramifications of those what’s that question I can’t talk about

feature product stuff but we’re all pretty excited about open source in general yeah yes yep you can if you look at dev twitter com in the documentation there is use cases there for manual installation as well where you can you know apply your own dependencies in Gradle and apply the plug-in and Gradle and then I think you do have to currently provision your app for the first time through the plug-in but after that one process is done the plugins not required the IDE plugins specifically because the plug-in records build events and it takes your mapping file for our proguard and uploads those so that crashlytics candy obfuscated NE tak traces coming in and it does that every build so that it’s seamless to the user yes what is the roadmap for the twitter api for fabric you mean because we don’t include all the api so is there a roadmap for the ones that we are going to include i don’t think i can specifically talk about that future roadmap and all that or hold on let’s make the student time check real quick guys at the back are we good on time still do we have any more couple more minutes a question three minutes okay perfect yes sure sure um it’s kind of a mix of things right now so the fabric android sdk gets tested on a cluster of three Jenkins boxes that all have moving over to robolectric for a lot of our tests as well so those get run on the JVM level then we have nightly builds that run that do a full set of integration tests that hit our back-end services as well and do the full integration stack yep anyone else going once going twice cool thank you for coming you