Enjoy Best of January

January 8th

ChatGPT Android by @skydoves gets a mention from the Google Developers Twitter account: https://androiddev.social/@skydoves/109654226719136891 and the Twitter link can be found here: https://twitter.com/googledevs/status/1612102389057593346

Drafting: Everyday Writing by @sen gets its 1.34 release. The drafting app gets some nice new features such as vibrating slightly when starting and finishing of moving custom toolbar icons and more. https://androiddev.social/@sen/109651286101040910

January 9th

Mishaal Rahman posted a round-up of what's new in the Android 13 QPR2 Beta release that happened today. You can find that here: https://androiddev.social/@MishaalRahman/109661618551076877 though it does lead directly to a Twitter list since threading on Mastodon is bit more work per Mishaal.

Great Post by spaghettiCode about how he wrangled a large codebase when starting new at a company

Ed :spaghettiCode: (@spaghetticode@androiddev.social)

When I joined ASOS, the size of the codebase was initially quite overwhelming and I found it difficult to know exactly what screens I was looking at when navigating through the app 😅 Thankfully, easy-dumpsys made this discovery process incredibly easy https://github.com/Kardelio/easy-dumpsys

Android Dev Social

January 12th

Hosting Mastodon on DigitalOcean/Kubernetes

socat TCP-LISTEN:1337 (@chuck@linuxlab.sh)

The folks over at DO have contributed a “running mastodon on kubernetes” guide, using their hosted services :) Might be worth checking out if you’re into managing infrastructure and thinking about starting your own instance. https://github.com/digitalocean/mastodon-on-kubernetes #mastoadmin #kub…

LinuxLab

January 16th

Our first guest blogger!

Article by Mark Murphy written about ActivityPub and Android: ActivityPub and Android (androiddev.blog)

January 17th

The DIY'ers of the Android community have delivered something that was quickly being requested by a lot of users. GoogleTV remote as a lock screen shortcut is available with AOSPMods. Original message here: https://androiddev.social/@MishaalRahman/109706513984072227 and the GitHub link is here: CHANGELOG: Added TV remote to lockscreen shortcuts · siavash79/AOSPMods@8bd10ef (github.com)

Compose Compiler 1.4.0 released with Kotlin 1.8.0 support. Compose Compiler  |  Android Developers

January 19th

Twitter officially puts a stop to all 3rd party Twitter apps from using the API: Twitter officially bans third-party clients with new developer rules - The Verge

January 21st

Security researcher Ken Gannon discloses two exploits that impact Samsung's app store on Android devices. https://androiddev.social/@MishaalRahman/109723958464120653

Google possibly to unveil about 20 new products and a new version of Google search at Google I/O and later this year: https://androiddev.social/@MishaalRahman/109722458643758585 original article here: Google Calls In Larry Page and Sergey Brin to Tackle ChatGPT and A.I. Chatbots - The New York Times (nytimes.com)

Dual eSIM support appears to start working for some Pixel 7 users: The Pixel 7 features powered by Android 13 APIs (esper.io)

January 22nd

Google lays off 12,000+ employees, some who had been with the company for 15 - 20+ years! Google employees scramble for answers after layoffs hit long-tenured (cnbc.com)

Microsoft lays off all of it's VR/AR teams along with about 11,000 employees. Microsoft Lays Off All Its VR, Mixed Reality, and HoloLens Employees: Report - ExtremeTech

January 23rd

Microsoft invests $10 billion into Open AI after laying off 11,000+ employees. Microsoft to Invest $10 Billion in ChatGPT Maker OpenAI (MSFT) - Bloomberg

January 25th

Grocy 3.0 for Android is released with a Material You redesign. Grocy is a Grocery Management app by Patrick Zedler. https://androiddev.social/@patzly/109752341647865930

Gradle folks talk about how Minecraft and suspicious gradle wrappers :eyes:

Paul Merlin 🍿 (@eskatos@mastodon.social)

On January 11th 2023, #gradle was contacted by MinecraftOnline about two unusual and suspicious Gradle wrapper JARs found in some of their repositories. Read about the story herehttps://blog.gradle.org/wrapper-attack-report Read about how to protect yourself against such #supplychainattacks here…

Mastodon

Updates to Sceneview from our Arcore friends

Kent Sinclair :androidEyes: (@Kents@androiddev.social)

pretty sweet update to SceneView library last week enabling compose support maintained by Thomas Gorrise https://github.com/SceneView/sceneview-android

Android Dev Social

How to connect to localhost from android emulator

Jeroen Mols (@Jeroenmols@androiddev.social)

Attached: 1 image Blogged: Connecting your Android emulator to a local development server. Neat little trick with etc/hosts that allows the emulator to access local IP addresses. 👉 https://jeroenmols.com/blog/2023/01/25/development-server-emulator/ #AndroidDev #server #react

Android Dev Social

January 26th

Mobile dev folks  and Maestro are continuing to kill it

Aaron Alaniz (@aalaniz@androiddev.social)

The folks at Maestro continue to amaze me. This latest change opens up a new set of product owners to contribute to automated testing. I also love the focus on maintenance a core tenant. https://blog.mobile.dev/announcing-maintainable-no-code-ui-automation-for-mobile-with-maestro-studio-16bb0c42da3b

Android Dev Social

January 27th

Trunks, another new app for Mastodon, gets an Android and iOS beta release with features such as: Multi-account support, quote toots, threaded replies, dark mode and instance browse. https://mstdn.social/@trunksapp/109759970359987018 and the Play Store link: trunks - Apps on Google Play

Ben's journey to repair an iphone using 3 50lb pelican cases worth of tools

Ben Oberkfell (@benlikestocode@androiddev.social)

Phone looks good as new, although it was so tedious ripping out that glue that I debated just tossing this and running to the mall for a new phone. All in all what I learned from this is that this was an incredible pain in the ass. Under no circumstances should anyone do this. I’m certain an App…

Android Dev Social

January 30th

You can now sign up for Google's new accessibility newsletter that should be sent out quarterly. Sign up for Google's Accessibility Newsletter

Compiling for OSX without a mac

Al Sutton (@alsutton@snapp.social)

This looks like an interesting way to get around needing a physical m1 mac for testing... https://github.com/sickcodes/Docker-OSX

Snapp.Social

Polls by Cliff Wade

https://androiddev.social/@cliffwade/109740641442401729

https://androiddev.social/@cliffwade/109734302398374356

https://seerofsouls.xyz/@Cliff/109716292458502438

https://seerofsouls.xyz/@Cliff/109705812255921808

Thanks folks, feel free to ping @friendlymike or @cliffwade on androiddev.social if any you'd like us to add any new links to February's newsletter

Big thank you to Cliff Wade for gathering the above material <3

Many engineers will tell you that one of the most complicated responsibilities of our job is naming things. Variables, classes, functions, everything we write requires conscious thought.

A special case among these are interfaces. This is because we not only have to name an interface, but we need to decide how to name the implementations as well.

Basic Convention

Traditionally, and by this I mean in the textbooks I read in college, interfaces and their implementations shared the same naming convention. I've seen this surfaced in one of two ways.

• Using an IInterface and Implementation convention:

interface IBookRepository {
    // ...
}

class BookRepository {
    // ...
}

• Using an Impl suffix:

interface BookRepository {
    // ...
}

class BookRepositoryImpl {
    // ...
}

This pattern often stems from before Integrated Development Environments (IDEs), where we had extra tools to differentiate between two classes. This naming convention gave us a quick way to scan files and see the difference between the two.

Problems

This approach, while it does clearly separate the convention between an interface and its implementation, has a couple inherent problems.

1. It assumes one implementation per interface. If we write a BookRepository and BookRepositoryImpl, but need to add a second, different BookRepository what do we call it? BookRepositoryImpl2?
2. Similarly, the Impl suffix doesn't provide any information about how the implementation operates. Is it pulling local data? Remote data? What is the data source used by BookRepositoryImpl? All of these questions require active investigation and diving into the code to understand and come back with a confident answer.

Alternatives

To avoid these problems, we can consider a number of alternative naming conventions for our interfaces and their implementations. As always, we have multiple different solutions, that you may choose to stick to one, mix and match, or change based on your situation. I've decided to highlight a few different approaches I have tried myself, and have heard used by others. Have different ideas? Let me know in the comments!

Naming With Data Source

If our application has a BookRepository data source interface, the implementation can be named based on the data source used to request books. Some examples may look like this:

interface BookRepository

class GoogleBooksBookRepository : BookRepository

class OpenLibraryBooksRepository : BookRepository

class NewYorkTimesBookRepository : BookRepository

Naming With Situation

Sometimes, our implementation might always be specific to the same data source/dependency. We still may want to leverage interfaces because it helps with testing, or some other situation. In these moments, we can consider naming our interface based on the situation it is being used in. For example, consider we include some interface for Crashlytics initialization. In our production app, we can name it accordingly.

interface CrashlyticsInitializer

class ProdCrashlyticsInitializer : CrashlyticsInitializer

Why is this better than CrashlyticsInitializerImpl? I believe this is better because it begins to set a precedent for other situations we might use a CrashlyticsInitializer. Situations like our device tests, where we can have a TestCrashlyticsInitializer or a special debug flavor that includes a DebugCrashlyticsInitializer.

Naming With Responsibility

Another way to look at this is to think of the reponsibility of a class. Perhaps your repository combines other data sources, with an offline first preference. You may consider something like this:

interface BookRepository {
    // ...
}

class OfflineFirstBookRepository(
    private val localRepository: BookRepository,
    private val remoteRepository: BookRepository,
) : BookRepository { 
    // ...
}

Other Considerations

The above suggestions are my personal preference, but there are other situations you may want to consider. By prefixing the implementations, searching for them in the IDE becomes slightly less straight forward. When searching in Android Studio, for example, if we start typing BookRepository, any files that are named BookRepositoryImpl get included in the same search. For that reason, you may consider taking the above suggestions, and combining them with the traditional suffix, like this:

interface BookRepository

class BookRepositoryGoogleBooksImpl : BookRepository

class BookRepositoryOpenLibraryImpl : BookRepository

class BookRepositoryNewYorkTimesImpl : BookRepository

Recap

At the end of the day, the naming convention you and your team use is a personal choice. By using interfaces, we're making a good choice toward scalable applications. The naming convention is mostly cosmetic, but I hope you've seen that it can serve a purpose for discoverability and quickly understanding the codebase by reading class names. What I believe matters most is that you take the time to think about it. Your conversation may ultimately end with "well, there's no dependency or situation specific usage here, so we just want to fall back on the Impl suffix. That's okay! Not all suggestions apply to all situations, but hopefully this post helps you find ways to provide more clarity in class names.

At Pocket we sat down a couple years ago to retire our old custom share UI and switch to the native one, but we uncovered two product requirements that we thought would block us:

• We wanted to customise the text we included in the share intent based on the target app.
• We wanted to track which apps our users choose.

Fortunately we dug into the documentation and discovered that both of these are possible with the native share sheet! Let me show you how!

Basic share sheet intent

But first, so we're all on the same page, here's our starting point—a way to create a basic native share sheet intent without any customisation:

fun createBasicShareIntent(context: Context): Intent {
    val sendIntent = Intent(Intent.ACTION_SEND).apply {
        type = "text/plain"
        putExtra(Intent.EXTRA_SUBJECT, "Subject")
        putExtra(Intent.EXTRA_TEXT, "Hello world!")
        addFlags(Intent.FLAG_ACTIVITY_NEW_DOCUMENT)
        addFlags(Intent.FLAG_ACTIVITY_MULTIPLE_TASK)
    }
    return Intent.createChooser(sendIntent, null)
}

Per-app customisation with EXTRA_REPLACEMENT_EXTRAS

Intent extras are an essential part of talking to the Android framework. This API goes the extra mile and lets you provide extra extras. No, really, meet Intent.EXTRA_REPLACEMENT_EXTRAS.

It lets you attach a Bundle of replacements to a chooser intent. Bundle is essentially a map. In this case the keys are package names of the target apps you want customised share text for. And values are Bundles of intent extras you want to add to or replace in the base intent. Yes, it's a Bundle of Bundles.

inception theme plays

Putting it together, here's how you would send a custom message to the official Twitter app:

fun createShareIntentWithCustomMessage(context: Context): Intent {

    // snip

    val replacements = Bundle().apply {
        putBundle(
            "com.twitter.android",
            Bundle().apply {
                putString(Intent.EXTRA_TEXT, "Bye Elon!")
            },
        )
    }
    return Intent.createChooser(sendIntent, null).apply {
        putExtra(Intent.EXTRA_REPLACEMENT_EXTRAS, replacements)
    }
}

You can call putBundle() multiple times, to provide (same or different) replacements for more than one app.

Note: this was added in API 21, which should be low enough these days to just use directly in any modern app. If you're stuck on a lower minSdkVersion, well.. here's an argument I would try to make in front of my team: "It isn't worth it to roll an entire custom share sheet just to support a custom message for users on a 9+ year old Android version."

Tracking share sheet clicks

Above we used a simple Intent.createChooser() call that accepts an intent and an optional title. But there's an Intent.createChooser(intent, title, intentSender) overload added in API 22, which accepts an optional IntentSender. It's basically a (pretty convoluted) way to add a callback when a user chooses an app from the sheet.

The callback lets you check the chosen app's package name and do anything you want with it. In the example below I'll call a (fake) analytics service to track the usage. Another use case—suggested by the docs—is remembering the last chosen app so you can provide it as a one touch share shortcut in your UI.

There's a couple of steps. First we need to create our "callback" in the form of a broadcast receiver that checks Intent.EXTRA_CHOSEN_COMPONENT. Here's an example receiver (you can name the class anything you want):

class ChosenComponentReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val component = IntentCompat.getParcelableExtra(
            intent,
            Intent.EXTRA_CHOSEN_COMPONENT,
            ComponentName::class.java
        )
        component?.let {
            analytics.track(it.packageName)
        }
    }
}

The second step is passing an intent sender that points to this broadcast receiver when creating the share sheet intent:

fun createShareIntentWithCallback(context: Context): Intent {

    // snip

    val pendingIntent = PendingIntent.getBroadcast(
        context,
        REQUEST_CODE,
        Intent(context, ChosenComponentReceiver::class.java),
        PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_MUTABLE
    )
    return Intent.createChooser(sendIntent, null, pendingIntent.intentSender)
}

It's not the most straightforward of things, but once you're done with the special ceremony required by the framework, it works like a normal callback or rather a normal broadcast receiver.

Conclusion

If you, your co-workers, your boss or—worse yet—your client thought you'll have to invest in building a custom share sheet, because otherwise there's no way to customise the shared text on a per-app basis or no way to track where your users share to, then you can be the hero that explains it is possible to save all this engineering and design effort and satisfy your requirements while showing the users a polished, familiar share experience.

Clients and bosses can be very creative, so there still might be some other reasons to implement a custom share sheet. But luckily the Android team handled at least these two common cases in the native one, which should greatly reduce how often you don't have a choice and have to go with a custom implementation. Thanks Android team!

You can see complete code examples from this post and the source of the post itself on Github (if you see anything from glaring errors to typos, please send me a PR!). If you have any questions or comments, reply to this toot.

That turned out well, I think.

A long-term side-effect, though, is that Android is now a mature OS with a mature ecosystem. In 2012, Android itself was still a "green field opportunity". In 2022... not so much. You can build a business around Android, but you need something more than Android. Similarly, being an Android app developer is useful but is not distinctive. There are lots of Android app developers, and you need to do something beyond that to "stand out from the crowd".

If I were a younger developer looking to be distinctive, or I were looking to start my fourth(!) business, I'd be looking into ActivityPub.

This blog is associated with androiddev.social, a Mastodon instance catering to Android app developers. Mastodon is gaining significant interest due to the issues surrounding Twitter. Mastodon is an app, an ecosystem, and an example of ActivityPub.

ActivityPub is a W3C specification for data exchange, focusing on social network-style apps. In particular, ActivityPub is designed around a "federated" set of servers, where the social network is not merely a network of users, but a network of sites that exchange data. The relationship between Mastodon and ActivityPub is roughly analogous to the relationship between podcasting and RSS: RSS says "this is a feed of content", while podcasting says "the content is metadata about podcasts and episodes".

ActivityPub is more than just Mastodon, though. If "Mastodon is Twitter, but using ActivityPub", then:

• Frendica might be Facebook, but using ActivityPub
• PixelFed might be Instagram, but using ActivityPub
• And much, much more

To me, ActivityPub has some "Android in 2010" vibes. There is a solid foundation along with early success stories, but there are few major players, none of whom are likely to completely dominate the space. While ActivityPub will lack the push of interested parties like Google and Samsung had for Android, its interoperable nature means that the success of things like Mastodon can help propel the entire ActivityPub ecosystem.

So, what could an Android app developer do who wants to get involved in ActivityPub? There are lots of possibilities, including:

• You could contribute to Mastodon client libraries, such as mastodonk or mastodon4j. Perhaps start small and useful (test cases! documentation!) and contribute in a more serious fashion as you gain comfort and acceptance.
• You could contribute to open source Mastodon clients, whether that is the official client or an independent one like Tusky. Again, perhaps start small and grow your involvement over time.
• You could move up the stack a bit and contribute to open source ActivityPub clients, such as Fedilab.
• You could create your own Mastodon or ActivityPub app from scratch, or fork an existing project and head off in your own direction.
• You could create your own Mastodon or ActivityPub library, perhaps targeting use cases or language bindings (Kotlin/Multiplatform? Flutter? React Native?) that you feel are under-served.
• You could write a library aimed at generic consumption of feeds, whether those are ActivityPub, RSS, Atom, GNU Social, ActivityStreams, or something else. While this library might wind up being focused purely on reading (rather than posting), it could open up possibilities for more apps to support more protocols.
• You could create an ActivityPub client aimed at a specific form factor: app widget, wallpaper app, TV app, watch app, car app, etc.

If you feel really adventurous, you could:

• Create a new protocol that uses ActivityPub. In other words, "my project is X, but using ActivityPub", where you come up with your own value for X. That could be tied to software development ("my project is F-Droid, but using ActivityPub", "my project is Stack Overflow, but using ActivityPub") or it could be broader in scope ("my project is Reddit, but using ActivityPub"). This likely will require some server-side development, in addition to client-side libraries and apps. On the other hand, "the sky's the limit".
• You could leverage that "generic consumption of feeds"-style library to create the truly universal timeline app.
• You could experiment with ActivityPub for situations where there may not be a stable Internet connection, or where Internet connections might be monitored continuously. Can you come up with an Android ActivityPub bridge that uses Bluetooth, WiFi Direct, or other communications protocol, to help conventional ActivityPub clients deal with inconsistent or inadvisable network access?
• You could aim to become a freelance developer advocate for ActivityPub. Perhaps your hope will be that if many ActivityPub apps become popular enough, ActivityPub will become a major piece of foundation technology. Crazier things have happened.

I think that the time is ripe for some good old-fashioned business model disruption. I think that ActivityPub is in good position to help with that disruption. And I think that there will be many opportunities for Android developers with demonstrated ActivityPub expertise, where that expertise can "open doors" that might otherwise not open for you. And, the nice thing is that even if ActivityPub does not become huge, getting involved with ActivityPub can cost you nothing more than time.

I look forward to what we build!

(and if somehow your project is "overcoming hair loss, but using ActivityPub"... ping me)

What a wild ride

Two months ago I was employed at Twitter which looked more and more like it was going to fall off a cliff. I had zero experience managing or deploying applications. Today, I am 6 weeks into my resignation and created a community of over 2000 Android Developers and a newly formed blog. I wanted to take some time and talk about how I got here and what makes androiddev.social what it is.

About Me

I've been a Twitter user  and an Android Engineer for over a decade. Before being a casual user, I was using Twitter as a poor man's pager duty at a small company. Over time Twitter grew to be my most visited website and eventually my employer. Over the past decade I was able to amass 7000+ followers making me more popular on Twitter than I have ever been anywhere. It truly felt like a place I felt comfortable to interact with folks. I used it to announce new libraries/blog posts, get support and generally talk to the Android community at large.

The Tipping Point

On Nov 4th, 2022, after an all-hands at work, I knew I could no longer be employed or a user of Twitter, I wanted to not only get off the platform but find a new home for others like me. Over the last few months I saw more and more people post their Mastodon handles on Twitter. I didn't have an account, and I thought it would be the right place to try.

Finding a New Home

At the time, most of the big servers were private so I looked for one that  I could pay for.  This led me to masto.host who was luckily still open for new sign ups. Rather than giving you an account on someone's server, masto.host let you pay for your own mastodon instance. I registered androiddev.social with Google domains and off I went. My goal was to advertise it a bit on some communities I am a part of and see if a few other folks wanted to join. We grew organically from the start.

Inviting Friends

Within 24 hours there was a waitlist of over 1000 android engineers. It was time to scale. I contacted our lovely host (who had closed public signups) and asked if they were willing to move us to a bigger VM.  They obliged and we were now ready for roughly 2000 members at a cost of $110 a month.

Legal Protection

Being paranoid I knew it was time to form an LLC, I've used incfile.com in the past and went with it again. It took a few days and about $400 for Android Dev Social LLC to be registered in NJ.  With a registered LLC, I could open a bank account.

Funding

While I was willing to pay a few bucks a month, it was clear that this would start costing more than I can carry on my own, so I solicited donations. My first try at payment processing was through Patreon.  The interface was easy and I was accepting payments within an hour of signing up.  Easy comes with a cost and it was as high as 20% of a donation. It didn't feel right to have someone's donation go to Patreon.

My next try was with Stripe. Stripe charged 2.9% + 30 cents per transaction. It was great for anything that was $5+ but was still not ideal for $1 donations (took 35 cents!).  I am still with Stripe because itworks globally and seems to be the cheapest I can find.

Asking for help

I welcomed our first mods as well. We now have a team of 7 moderators reviewing sign ups, banning content and building things like this blog.

Two Weeks In

By November 14th, androiddev.social had 1,600 users, 7 moderators, an LLC and a bank account. What started as a distraction from the Twitter tire fire was blossoming into an ever growing community.

Outpouring of support

Over the last two months I have received 200+ donations ranging from $1/mo from over 100 members to large one time donations from Droidcon and Android Developers (Google). Overall we have collected over $7,000 allowing us to prepay for a year of hosting and expand to things like this blog.

Introducing blog.androiddev.social

Besides a Twitter replacement, there was one more online tool I was hoping to create for the Android community and that was a Medium replacement. Many Android engineers previously published on Medium. In recent years, policies there have made it increasingly difficult to use for free. Since we have extra funding, I spent the last few days getting a ghost blog hosted on Digital Ocean.  This blog post along with many more to follow are being hosted on a $12 a month Digital Ocean droplet.  We'd love to grow this as a public publication so if you are interested in contributing please reach out to admin@androiddev.social.

Moving Payments

Ghost is much fancier than what I remember it being from a few years ago. Ghost 5 is a full featured CMS rather than a blogging platform. It also has Stripe integration and member management. As of yesterday, we have migrated our donation page to be within Ghost https://blog.androiddev.social/#/portal/. The biggest addition here is ability to let folks increase/decrease/cancel their donation levels as well as automation around sending invoices and receipts. Think of it as all the nice things we had with Patreon but being able to get it for free, as part of our Stripe fees.

Plans for 2023

Over the next year I expect to double the number of folks that use androiddev.social. I also hope to expand this blog to be a newsletter and general center for Android communication online. We are working on merchandising as well. Donations will be eligible for stickers or t-shirts.

On the business side I need to find an accountant and figure out taxes. I’m also looking for a few larger sponsors to help with efforts like bounties for app development. Please contact us at admin@androiddev.social if you'd like to support us at the corporate level.

Big thank you to our mods and everyone who has helped along the way.

Donations are appreciated and can be made through:   https://blog.androiddev.social/#/portal/

Current subscribers through stripe - feel free to unsubscribe here and then subscribing above. The advantage will be access to a portal we built on this blog. The portal allows you to update or cancel your subscription.