DEV Community: Anita Singh

Terrified of speaking at a conference? Submit anyway!

Anita Singh — Sun, 30 Dec 2018 18:04:24 +0000

I never thought I'd face a room full of people and speak words out of my own free will, but here we are! This was my first year of submitting to tech conferences, and I had the pleasure of speaking at three of them - Android Makers, Droidcon Berlin and 360AnDev ❤.

I was nervous throughout the process - from picking a topic, writing an abstract, to delivering the talk. So much so that when I got my first rejection, I was relieved and ready to throw in the towel!

I'm glad I didn't, because sharing what I learned through speaking has been an incredible experience, even though 100% terrifying. In this post, I will share what worked for me in getting started:

Finding a topic

I initially didn't feel like I was an "expert" on any one topic, so wasn't sure what I should speak about. But I was taking the wrong approach, as speaking is just about sharing what you know (or will learn), and that is it!
No two people explain concepts the exact same way, so it absolutely worth sharing your knowledge even if it is something that has been spoken about before. People will come to your talk to hear about your experience and perspective on a topic, so don't hold back!
If speaking is about sharing what you know…well, what do you know? To refresh your memory, I recommend making a list of ALL the projects you worked on in the last couple of years and what you learned, spare no detail! Then proceed to summarise each point with a phrase, like "worked with Android gestures" to extract potential topics out of them.
If you feel unamused by the topics related to your past projects, make a second list of topics you wish you knew more about. If you think you will be able to sufficiently explore a topic before the conference, then it is fair game!
My advice would be to pick up to three topics that you are either most excited or confident about (or both), and get started!

Submitting abstracts to Call For Papers (CFP):

First, read the conference's website where they post their CFP. Often they list topics or what they are looking for, which can help you brainstorm or tailor your abstract.
Go through websites of conferences earlier in the year and read the topic proposals to get a sense of how to structure them. You will see that abstracts are a talk’s MVP (minimum viable product) as it is the minimum amount of effort you need to make. You only have to write the talk once it gets accepted!
Keep your abstract succinct and focus on what the audience will learn from your talk. The first two conferences I submitted to used language like "I will share how I.." instead of saying "you will leave this talk knowing how to..". Don't know if this is a coincidence, but once I changed the language, my talk got accepted!
Rejections are part of the process. As mentioned above, get feedback from the community as early as possible and don’t be like me and wait for rejections to do this. Don’t hesitate to ask for feedback from the conference committee either, but don’t feel down if you don’t get a response since they are busy people dedicating their free time for this.

Tips on overcoming your nerves

Practice slowing down. When you are in front of people, adrenaline kicks in and you will likely speak at a faster speed than anticipated. Record yourself if you are feeling brave to improve on your delivery (but don't obsess!).
Give the first version of your talk at a safe space like your friendly local meet-up or in front of your colleagues and ask for feedback. I recommend taking questions in these safe spaces as they can help you improve the content of your talk for next time.
Be mindful of your posture and body movements when delivering the talk. Be 100% yourself, but the nerves can result in you playing with your hair (guilty!), sleeves, and so forth while giving the talk, which can be distracting for the audience.
This might seem silly, but do the power pose and give yourself a pep talk right before the talk! If possible, surround yourself with positive people leading up to it, this helped me the most.
The audience is on your side, and if you think you messed up during your talk, just keep going. Chances are nobody noticed, you are your biggest critic, and we are only human! I blanked out once and I internally panicked, but it looked like I was just taking a breath to everyone else :-).
You don't have to take questions on the big day, and it is perfectly acceptable to say you will get back to someone if you don't know the answer. The audience will not mind getting their time back.
Finally, don't take yourself too seriously, you are not carrying the weight of world peace on your shoulders! That worst case scenario that you are dreading will NOT happen since you are so nervous about it. And besides, what is the worst that could happen?

I have anxiety about this whole process, and what convinced me is if I don't enjoy speaking, I never have to do it again, but it is worth trying at least once.

You don't have to do this alone, lean into your developer community and check out organizations that can support you, like Toastmasters, Write/Speak/Code, Women Techmakers Berlin and so forth.

I hope the above tips are helpful, would love to hear your thoughts in the comments below or on Twitter. Looking forward to hearing you speak, here are some conferences that you can submit to right now!

Downloadable Fonts for Android

Anita Singh — Wed, 20 Dec 2017 22:30:18 +0000

I recently had the pleasure of using the newly supported Downloadable Fonts feature that was introduced with Android Oreo, when changing Winnie’s font from Roboto to Lato.

Along with Fonts in XML, Support Library 26 introduced support for Downloadable Fonts, with backwards compatibility till API 14. Historically, using custom fonts have usually required the use of third-party libraries, so it was nice to see more support from the Android framework itself.

What is Downloadable Fonts, and why use it?

Downloadable Fonts allow the ability for apps to request fonts from a font provider application instead of including font files in the apk or downloading it themselves. A font provider application retrieves fonts and caches them locally so that other apps can request and share fonts. How cool is that!

Google Play Services (on devices with version 11+) is one such font provider, which I used for Lato as it is a Google Font. There isn’t documentation yet on how to implement your own font provider if you were to use a custom font not available through Google Play Services, however you can use fonts in XML which is still an improvement over what it used to be!

Apps using Downloadable Fonts make a FontRequest using the FontsContract API which retrieves the Typeface from the Font Provider. The Font Provider does not need to download fonts if it already exists in the Font cache.

Developers don’t need to use these APIs directly if using Downloadable Fonts through XML, which is described more in the next section.

Advantages of using Downloadable Fonts:

1) Reduced APK size — which can significantly impact your app installs!

2) Since the apps can share fonts from the same provider, this results in less usage of precious memory, disk space and cellular data. Can you guess how many Roboto font files are in your phone’s storage right now? 🙀 (yes there are apps that have them in their APKs).

Great, let’s get started!

There are three ways of implementing Downloadable Fonts in your app — using Android Studio & Google Play services, programmatically or via the Support Library. I used Android Studio to generate the required files, and used the Fonts in XML feature from the Support library to apply the downloaded fonts.

I decided to do it via XML because then you can declare the required fonts in your app’s manifest file, which allows the framework to download them ahead of time. If doing it programmatically, you can only request for fonts after the app is launched, which can cause a delay in the first layout time. Also, it is less work do it via XML!

1) If you want to use Android Studio to generate the required files, then you’ll need version 3.0+. Add the following (version 26+) to your module’s build.gradle:

implementation "com.android.support:support-compat:27.0.2"

2) Select a text view in your app that you want to apply the font to and click on the fontFamily attribute under Attributes in the graphical layout.

Select the “More Fonts…” at the bottom, which will open the dialog below.

3) Make sure to have “Create downloadable font” selected. This results in three files being downloaded — lato.xml, font_certs.xml and preloaded_fonts.xml.

lato.xml

This file contains the font attributes for loading a Typeface from the Google Fonts Provider Application.

<?xml version="1.0" encoding="utf-8"?> <font-family xmlns:app="http://schemas.android.com/apk/res-auto" app:fontProviderAuthority="com.google.android.gms.fonts" app:fontProviderPackage="com.google.android.gms" app:fontProviderQuery="Lato" app:fontProviderCerts="@array/com_google_android_gms_fonts_certs"> </font-family>

font_certs.xml

The system uses these certificates to verify the font provider’s identity, to avoid getting fonts from an unknown source. If using the steps above, Android Studio should have automatically generated the string certificates for dev and prod in font_certs.xml below.

<?xml version="1.0" encoding="utf-8"?> <resources> <array name="com_google_android_gms_fonts_certs"> <item>@array/com_google_android_gms_fonts_certs_dev</item> <item>@array/com_google_android_gms_fonts_certs_prod</item> </array> <string-array name="com_google_android_gms_fonts_certs_dev"> <item>  </item> </string-array> <string-array name="com_google_android_gms_fonts_certs_prod"> <item>  </item> </string-array> </resources>

preloaded-fonts.xml

This file is referenced in the Android manifest which helps the framework pre-load fonts to avoid delays when the app is launched.

<?xml version="1.0" encoding="utf-8"?> <resources> <array name="preloaded_fonts" translatable="false"> <item>@font/lato</item> <item>@font/lato_bold</item> </array> </resources>

4) Make sure this line is added to your app’s Manifest file, Android Studio should have done this automatically:

<meta-data android:name="preloaded_fonts" android:resource="@array/preloaded_fonts"/>

5) Great, now you are ready to apply the fonts in XML!

<style name="AppTheme" parent="Theme.AppCompat.Light.NoActionBar"> <item name="colorPrimary">@color/colorPrimary</item> .... <item name="android:fontFamily">@font/lato</item> </style>

All I had to do was set the font family in the app’s theme to get TextViews throughout the app to change to Lato, including parts that were bold or italicized. However, if you want to configure the weights, you can follow the same steps to get Lato Bold using Android Studio, and change the weight manually in lato_bold.xml that you can then apply in XML layouts:

app:fontProviderQuery="name=Lato&weight=700" //can modify the weight here

The whole thing felt like magic! But…

Gotchas

When using Support Library 26, I noticed that the toolbars throughout the app was still in Roboto, resulting in a hideous Roboto-Lato combination! Even explicitly setting the fontFamily of the toolbar in XML didn’t work. This is because Toolbar does not implement the fontFamily property, like a TextView does.

Including the fontFamily in an XML style and setting that to be the toolbar’s app:titleTextAppearance worked — the toolbar titles were now in Lato! Good news is that this seems to be fixed in Support Library 27, so this workaround shouldn’t be needed.

There were a couple of other places where Lato did not get applied — one where I was dynamically creating textviews with bold styling, and the bottom navigation view for which I used a third-party library. I initially thought that this would do the trick:

val typeface = ResourcesCompat.getFont(this, R.font.lato) //for the third-party bottom navigation view bottomNavigationView.setDefaultTypeface(typeface) //for the bolded text view textView.setTypeface(textView.getTypeface(), Typeface.BOLD)

I used the ResourcesCompat.getFont() method to load the Typeface and set it on both views, and voilà, there was no more Roboto! However, at one point I saw a ResourcesNotFound exception when setting the Typeface for the BottomNavigation using this method.

Essentially, if the font hasn’t been loaded by the time this method is called or the user doesn’t have the required version of Google Play Services, it will throw this exception. The safest way to avoid this is to load the font programmatically, if you are unable to set the style through XML. Here is the official documentation on how to do that.

There is also this crash with FontsContractCompat in 27.0.2, it has been fixed for a future release of support library and doesn’t seem to be an issue in 26.1.0

Other requirements and limitations worth noting:

1) Your compileSDK should be at least SDK 26, and if you want to use Android Studio to generate the font files, it should be version 3.0+. If programmatically or using Fonts in XML to apply Downloadable Fonts, you must use at least Support Library 26.

2) Using Google Play Services as a font provider works on devices that have version 11 and above, otherwise it uses the default system font.

3) As mentioned earlier, you may not be able to use Downloadable Fonts if you’re using a custom font that isn’t available through Google Play Services. You might have to write your own custom FontProvider in this case which doesn’t have documentation yet.

I (surprisingly) enjoyed transitioning our app from Roboto to Lato thanks to Fonts in XML & Downloadable Fonts, hope you enjoy these features too! I’d love to hear from you in the comments or on Twitter, and don’t forget to 👏 the post :).

Flying Solo with Android Development

Anita Singh — Wed, 22 Mar 2017 19:31:06 +0000

My Android career started two-and-a-half years ago, when I transitioned from back-end development to mobile development, along with the support of a four-person Android team. A year later, I joined a series-B startup, where I was one of two Android engineers for most of my time there. Working on small teams was a great way to have independence and also learn from other engineers.

But then, five months ago, I took a leap from small team to no team when I joined a seed-funded startup of six employees as their only Android engineer. In my new role, I’ve been building the Winnie app from scratch, which just got released!

It turns out this was a big leap. Flying solo has been a challenge, but it’s also been extremely rewarding. I’ve learned along the way that there are pros and cons to working alone. Most importantly, there are things you can do to set yourself up for success. Here are some of the tactics that have helped me thus far.

Be connected with the community. Do your homework.

One of my worries about going solo was not having Android teammates to discuss new ideas with or be a sounding board for their ideas, which I’ve thoroughly enjoyed in my previous roles.

The good news is that there are tons of resources available online to expand your knowledge and perspectives. From online talks from various conferences such as DroidCon, 360|AnDev, etc to your timely dose from Fragmented Podcast, Android Dialogs and Android Weekly, there are many ways to broaden your thinking.

My personal favorite is Caster.io — the code samples with every bite-sized lecture keeps me on my toes! Local meet ups or virtual communities like the AndroidDev subreddit, Google+ communities, Slack groups and Twitter are great places to continue the conversation and ask questions when stuck!

Review your own PR’s and maintain high standards.

I highly encourage opening PR’s and then reviewing them yourself. It will feel silly commenting on your own PR’s, but I think it’s a healthy habit when working by yourself (also discussed in this relevant Android Dialogs episode).

I do a first-pass using the preview feature of Github, and then let it sit for a while before I look at it again. I try my best to review my PR’s as I would review PR’s from a peer, and thus hold myself to the same standards. A second look at all your code also helps catch bugs and edge-cases, as well as keeps your code consistent and clean.

A “bad” pattern is often better than no clear pattern.

You will have to make many decisions — should you use MVVM, MVP, Flux, and/or another architectural pattern? Fragments or custom ViewGroups? What should have abstractions and what shouldn’t?

It’s not uncommon to start with one pattern and then realize another pattern is better when you’re at the beginning of a project, which leads to either some refactoring or diverging of patterns.

While it makes sense to break your patterns for certain cases, it is best to be mindful of refactoring and changing it consistently everywhere when you’ve found something you like better. This might sound obvious but it’s easy to just use the new pattern for all the new code when you’re working by yourself, which can quickly result in a confusing and incoherent codebase before you know it! Even if the patterns aren’t great, consistency makes it easier to fix down the line.

Strongly consider using Kotlin.

Especially if you are starting from scratch! If not, consider giving it a shot with the next class you’re going to write.

I didn’t end up using Kotlin because I wasn’t confident about pitching the idea, since I had zero experience with it at the time and didn’t want to discourage the back-end Java developers on the team from contributing to the codebase.

However, after watching Christina’s talk on Kotlin and doing more research, if I were to do it again, I’d have at least tried it. Kotlin has plenty of advantages — even just avoiding crashes because of null pointer exceptions and not dealing with Java boilerplate has me sold! This talk by Jake Wharton is also a great starting-point.

Try to keep control by not being too reliant on third-party libraries.

I remember spending a bunch of time trying to decide on a library to use for MVP, as there are many of them. While being spoiled for choice is a great problem to have, I ended up implementing a simple version myself and have been very happy with it!

When choosing what third-party libraries to use, I’d suggest considering whether you really need it and how it would restrict the development of the app in the future — does it make unit testing harder? Does it restrict using features that Android gives for free, like transition animations between screens? Is it actively under development and do many apps use it? This helped me make informed trade-offs and decisions.

I’d recommend optimizing for retaining as much control as possible without reinventing the wheel. There is a library out there for pretty much everything, but you’re better off implementing some stuff yourself.

Have a testing and accessibility plan.

If you are building from scratch, it is very exciting that you have a chance to do this right from day one! And if not, you can try doing it right with all the new code you write!

It isn’t uncommon that testing and accessibility take the backseat when trying to hit aggressive deadlines — and when you’re solo, it can be harder to find time for it since you aren’t sharing the load with anyone else.

I will admit that I am only in the beginning of this journey myself, however I wrote code with testing in mind by using dependency injection, Model View Presenter pattern, exposing only interfaces of my model objects to the UI, and so forth with the goal of making it easier to test. I also had CircleCI build after each commit from the beginning of the project, as a sanity check and to get closer to running tests.

For accessibility, I add content descriptions whenever I can, and use the Accessibility Scanner before a release to figure out what I should focus on next. There is definitely more work to be done, but it is a start. Here is a great talk by Kelly Schuster on actionable steps that developers can take to make their apps more accessible.

If you aren’t able to spend time on writing tests, then have a manual testing plan handy. For example, write down different test cases (positive, negative) in a document for each feature and make sure to test those before every release! Set deadlines for yourself to start writing tests, and do the same for accessibility improvements, otherwise they’ll most likely never get done.

Tell your iOS designers that they are wrong and look for potential Android converts :-).

Don’t be afraid to stand up for what is right for your platform! When you’re solo, you are responsible for bringing others up to speed with the latest Android UI patterns, as well as the codebase.

I mostly worked off iOS screenshots but used the material design spec and well-designed Android apps as resources to help me convert those designs to Android. Also, there is nothing better than linking to the official material design documentation to make your point!

Regarding the codebase, I helped bring my CEO up to speed with our architecture and concepts like MVP, Dagger2, RxJava2 and so forth when she helped out for a couple of months. I’d recommend keeping a lookout for potential Android converts, as explaining your decisions to someone or teaching them a new concept helps you really own it or alternatively, realize your mistake.

Go to beta as early as possible.

This is applicable if you are working on app that hasn’t been launched yet or are making major changes to an existing app. Google play has an alpha and beta channel, and within the beta channel you can either have a closed or open beta.

If you are working on an existing app, you can still have a beta run in parallel, so long as it’s version is higher than the production app. If it is an open-beta, users will be able to opt in on the playstore or by clicking on a link. If you are trying to test out changes of a smaller scale, then staged-rollouts might be better for that.

If you are working on a new app, I’d suggest having a closed beta as soon as possible, and converting that to an open beta when it’s ready, before the launch. Our first closed beta had very few features, but it helped us iron out bugs early on, get onto a regular release train and receive valuable feedback throughout the process. This also resulted in a stress-free and smooth launch!

Going solo for the first time is a great learning experience as you get to challenge yourself like never before, be more self-reliant, exercise total creative control over the codebase (for better or for worse), learn more about what you like, and deal with making mistakes that you only have yourself to blame (yay). I was nervous about going solo but it turned out to be a fun experience as the above suggestions worked for me. I hope they will be helpful for you too!

Are you considering going solo or want to share your experience? I’d love to hear from you! Please comment on the post, or feel free to get in touch on Twitter.

Nevertheless, Anita Singh Coded

Anita Singh — Tue, 07 Mar 2017 07:34:46 +0000

I began coding because...

I happened to take a class my freshman year of college where we programmed these little robots to navigate mazes and perform tasks - I became obsessed with my robot and subsequently decided to major in Computer Science!

I'm currently hacking on...

Building the Winnie Android app from scratch! Winnie connects you with your local network of parents and helps find great destinations for kids, anywhere you go.

I'm excited about...

Building technology with a social purpose and awesome user experience!

My advice for other women who code is...

Prioritize your health and happiness above all else. Persevere. People will try and box you into stereotypes - ignore them. It's okay to not be perfect and not have all the answers, you are NOT an impostor.