{"id":1686,"date":"2017-11-22T03:44:55","date_gmt":"2017-11-21T19:44:55","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/vsappcenter\/?p=1686"},"modified":"2019-02-16T15:30:39","modified_gmt":"2019-02-16T22:30:39","slug":"how-we-build-sdks-developers-love","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/appcenter\/how-we-build-sdks-developers-love\/","title":{"rendered":"How We Build SDKs Developers Love"},"content":{"rendered":"<p>We\u2014the Visual Studio App Center development team\u2014have released SDKs for Android, iOS, React Native, UWP and Xamarin, with more <a target=\"_blank\" href=\"https:\/\/docs.microsoft.com\/en-us\/appcenter\/general\/roadmap\" rel=\"noopener\">in the works<\/a>. As we build new tools, we do so knowing that many are successors to popular SDKs, like HockeyApp, that developers already use and love (for good reason).<\/p>\n<p>When we started working on App Center, we knew we had to not only build new, exciting features, but take the existing SDKs\u2019 hard-earned developer satisfaction into account. We\u2019ve learned a lot along the way (and continue to learn!), and we\u2019re sharing our story today to help you build your own amazing SDKs that your team, friends, and developers around the world will love to use.<\/p>\n<p>So, how are we making our SDKs better than ever, so it\u2019s easier for you, and all developers, to ship great apps?\n&nbsp;<\/p>\n<h3>Step 0: Step Back<\/h3>\n<p>With years of customer feedback from the existing SDKs , it was tempting to start coding. But, we\u2019re not ones to succumb to temptation; we began with a pause, and this was possibly the most productive part of the process.<\/p>\n<p>Here\u2019s why:<\/p>\n<ul>\n<li>Some of us hadn\u2019t worked together before. Spending time discussing perspectives and working through a few \u201carguments\u201d helped us build a team.<\/li>\n<li>We gave ourselves an opportunity to take a step back, reevaluating and fleshing out our spec (before we got too deep in development).<\/li>\n<li>We established core values that have guided us throughout the whole process of designing and coding our SDKs. Read <a target=\"_blank\" href=\"https:\/\/blogs.msdn.microsoft.com\/vsappcenter\/how-the-visual-studio-mobile-center-team-does-code-review\/\" rel=\"noopener\">our post on code review<\/a> for more info.<\/li>\n<\/ul>\n<p><img decoding=\"async\" src=\"\" alt=\"\" width=\"1024\" height=\"683\" class=\"aligncenter size-large wp-image-1695\" \/><\/p>\n<p><em>Champions of open-source: Linux Foundation Executive Director Jim Zemlin, Microsoft EVP Scott Guthrie and GitHub CEO Chris Wanstrath at Microsoft Connect(); 2016<\/em><\/p>\n<h3>Step 1: Work in the Open<\/h3>\n<p>We wanted to open-source our SDKs and work in public as much as possible. With full support from our leadership team (in 2016, Microsoft was named <a target=\"_blank\" href=\"https:\/\/octoverse.github.com\/\" rel=\"noopener\">the #1 contributor on GitHub<\/a>), we made our SDK public the day we entered public preview. We do pull requests in the open, and our users contribute their code, file issues, and ask for features in our public repos.<\/p>\n<p>Was working in public a little terrifying at first? Yes, but it&#8217;s also very rewarding. Other developers see what we&#8217;re working on, support is much more transparent, and we foster a greater sense of trust, since anyone can verify that things work \u201cas advertised.\u201d There are no black boxes, just coding, learning, and iterating.<\/p>\n<p><a target=\"_blank\" href=\"https:\/\/github.com\/search?utf8=%E2%9C%93&amp;q=org%3AMicrosoft+mobile+center+SDK&amp;type=\" rel=\"noopener\">Head over to GitHub<\/a> to join the discussion, fork your own code, and see what we\u2019re up to.<\/p>\n<h3>Step 2: Delight Developers<\/h3>\n<p>As developers who use SDKs ourselves,user experience is extremely important to us. We want to create SDKs that are accessible to any developer (inexperienced to expert), easy and quick to use, and just generally delightful.<\/p>\n<p>But what\u2019s a \u201cdelightful\u201d SDK experience? We use <strong>four guiding principles<\/strong>:\n&nbsp;<\/p>\n<ol>\n<li><strong>Stay Transparent<\/strong>: We weighed two fundamental approaches to setup, start and customization: configuration in code vs. configuration through a configuration file. Initially, the file-based approach sounded appealing; developers would add a dependency to App Center in their apps, download a configuration file, and be ready to go. But ultimately, <strong>we opted for a code-based solution<\/strong>, because:\n&nbsp;<\/p>\n<ul>\n<li><strong>Less Complexity<\/strong>: A configuration file makes it easy to get up and running with an SDK, but sophisticated functionality (e.g. adding APIs to allow configuration at runtime) often results in complex scenarios that require configuration files and code. This makes it harder for to keep track of what, where, and when you\u2019ve made changes \u2013 which is exactly what we were trying to avoid.<\/li>\n<li><strong>Avoiding the \u201cBlack Box\u201d<\/strong>: Configuration files get messy. As multiple developers modify a project, they end up with a file containing configurations and variables that they&#8217;ve never seen before. On top of that, they need to be human readable, so they are either JSON or XML. While both are definitely human-readable, they are not fun to look at.<\/li>\n<li><strong>Ultimate Developer Control<\/strong>: There\u2019s something appealing about being able to start, stop, enable, configure and customize an SDK to your needs. With code-based solutions, no additional config file can override what you\u2019ve done in your setup code \u2013 and, with our SDK, developers explicitly enable each App Center feature.<\/li>\n<li><strong>Simplified Support<\/strong>: As explained, it\u2019s very likely to end up with configuration and setup done in code and the configuration file. On the flip side, with code-based solutions, you configure SDKs in one place (code), so you \u2013 and your QA team \u2013 easily verify and debug issues. In addition, it\u2019s a lot easier for us and our support team to understand what\u2019s going on in case where something doesn\u2019t work right for you.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<li><strong>Keep it Simple, Within Reason<\/strong>: Simplicity is key. We know developers are more likely to use something, and continue to use it, if it\u2019s dead simple. With this as our guiding principle, we made sure our two-step integration was just:\n&nbsp;<\/p>\n<ol>\n<li>Add the dependency to App Center (using your target platform\u2019s preferred method to manage dependencies).<\/li>\n<li>Add one line of code.<\/li>\n<\/ol>\n<p>&nbsp;\nLike all developers, we\u2019re always balancing functionality tradeoffs and we avoid adding complexity whenever possible \u2013 but we\u2019re flexible. For example: initially, we planned to limit ourselves to a single API to start the SDK, but conversations with our customers helped us realize that we needed to offer more customization options. In the end, we chose to make it possible to setup and start the SDKs with just one line of code, but we provide various APIs to allow for custom behaviors. This adds complexity but helps us achieve our mission and fit into any developer\u2019s workflow.<\/p>\n<p>Still, we say \u201cno\u201d more than we say \u201cyes\u201d (or, at least to adding a new API or making any changes that complicate the product).<\/li>\n<p>&nbsp;<\/p>\n<li><strong>Tread Lightly<\/strong>: Ease-of-use is irrelevant if your product or service causes compiler warnings, slowdowns, or (worst) crashes. We\u2019ve structured our team and our development processes to uphold utmost quality and minimize overhead with two key mandates:\n&nbsp;<\/p>\n<ul>\n<li><strong>Reduce Performance Impact<\/strong>: Our SDKs are modular, so our users only integrate what they need. We want you to use all of our amazing features, but you might have other plans or existing tools. We require one very small binary that includes shared code, (e.g., for network i\/o), and each App Center service is its own module. While our total footprint\u2013even with every service active\u2013is minimal, we want to provide the most optimized experience we can, so if you\u2019re not using a service, you can pare down your app size even more. That said, even if include all of our services, the App Center SDKs are very small.<\/li>\n<li><strong>Reduce Human Error<\/strong>: As Lukas\u2019 shared in <a href=\"https:\/\/blogs.msdn.microsoft.com\/vsappcenter\/how-the-visual-studio-mobile-center-team-does-code-review\/\" rel=\"noopener\" target=\"_blank\">How We Do Code Review<\/a>, we all review team members\u2019 pull requests. We set up continuous integration and continuous deployment to prevent errors in the first place and help us detect errors as soon as possible. Lastly, we perform integration tests and end-to-end UI tests on a huge variety of devices and OS versions. We not only build App Center, we use App Center and are huge advocates of CI\/CD, automation, and eliminating repetitive, error-prone manual processes.<\/li>\n<\/ul>\n<\/li>\n<p>&nbsp;<\/p>\n<li><strong>Be Consistent<\/strong>: Each mobile platform and toolchain has its own APIs, programming languages, history, and conventions. To be \u201cdelightful,\u201d our SDKs need to respect each environment\u2019s conventions, and our APIs need to feel natural and familiar.At the same time, we want to be as consistent as possible across all of our SDKs, simplifying life for multi-platform developers (\u2026and our team!).\n<p>It\u2019s a balancing act, but we\u2019ve found the solution that works for us and for our customers: regardless of language or framework, just one line of code to configure and start the App Center SDK. Here are some examples from the Java, Swift, and C# (Xamarin) implementations:<\/p>\n<p><code>AppCenter.start(getApplication(), \"{Your App Secret}\", Analytics.class, Crashes.class);<\/code><\/p>\n<p><code>MSAppCenter.start(\"{Your App Secret}\", withServices: [MSAnalytics.self, MSCrashes.self])<\/code><\/p>\n<p><code>AppCenter.Start(\"{Your App Secret}\", typeof(Analytics), typeof(Crashes));<\/code><\/p>\n<p>Each is easily understandable to developers well versed in a development language, but there\u2019s enough consistency across the implementations to make multi-platform development simple.<\/p>\n<p>Lastly, to make it easier to learn how to use new modules, we\u2019re consistent across all of our SDKs. For example, if you\u2019re using the App Center Analytics, there\u2019s a method to enable or disable it at runtime. When you add App Center Push to your app, you can (rightfully) assume that there\u2019s a method with the same signature to enable or disable at runtime, too.<\/li>\n<\/ol>\n<h2>Here\u2019s to the Future<\/h2>\n<p>No process is perfect (continuous innovation FTW!), but these principles allow us to focus on our mission, yet are flexible and applicable to a wide range of circumstances.<\/p>\n<p>We\u2019re excited to use them as our guide in our next phase of development, and further refine them as we tackle and ship the many features on our roadmap.<\/p>\n<p>We\u2019re on a mission to develop SDKs, tools, and services that developers love, so you focus on delivering apps that users love. Get started for free with App Center to explore our SDKs and developer-friendly APIs and services, and let us know what you think!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>We\u2014the Visual Studio App Center development team\u2014have released SDKs for Android, iOS, React Native, UWP and Xamarin, with more in the works. As we build new tools, we do so knowing that many are successors to popular SDKs, like HockeyApp, that developers already use and love (for good reason). When we started working on App [&hellip;]<\/p>\n","protected":false},"author":42,"featured_media":38034,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[16],"tags":[],"class_list":["post-1686","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mobiledev"],"acf":[],"blog_post_summary":"<p>We\u2014the Visual Studio App Center development team\u2014have released SDKs for Android, iOS, React Native, UWP and Xamarin, with more in the works. As we build new tools, we do so knowing that many are successors to popular SDKs, like HockeyApp, that developers already use and love (for good reason). When we started working on App [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/posts\/1686","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/users\/42"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/comments?post=1686"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/posts\/1686\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/media\/38034"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/media?parent=1686"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/categories?post=1686"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/appcenter\/wp-json\/wp\/v2\/tags?post=1686"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}