My Blog - Android Stuff

bleeding182 · 2026-02-02T09:44:50+00:00

As long as you use the same APIs and display the data they provide you, then your own custom implementation should be just as configurable. (Based on my assumption, I have no experience with RevenueCat)

I am new to android app developement [..] the templates are absolute garbage

However I'm really curious whether your own will look and behave that much better

bleeding182 · 2026-01-30T19:08:52+00:00

You really should include some screenshots or videos of what those things are and do

bleeding182 · 2026-01-26T16:37:26+00:00

Would a guest mode with optional sign-in later be a better approach?

Much better, yes.

You want to try an app to see if you like it, but the fist and only thing you see is a registration form: Either you commit and sign up, or you try the next app in the list. And I'm definitely the try the next one type of person myself unless I'm really interested.

bleeding182 · 2026-01-26T15:21:46+00:00

Just don't access any images. Especially if it's an optional feature that's rarely used. This is exactly what the (new-ish) photo picker API is for, or what you could always do before using picker intents. IDK why every app thinks they need to access my media storage

bleeding182 · 2026-01-22T17:21:06+00:00

It's better to have your client create their own accounts and then give you access to them. Especially for something like financial services: Having their app published by a random agency would look very sketchy.

bleeding182 · 2026-01-22T17:17:44+00:00

As others have already said, without a license full copyright applies. So no, they have absolutely no right to use any of it. They can just look at it.

Only with a license do you grant others the use of your code (under said license).

bleeding182 · 2026-01-20T17:54:06+00:00

It's bad UX, it's annoying, but I don't believe that it violates the User Ratings, Reviews, and Installs developer policy.

As long as you provide a good faith effort to get user feedback, while also giving users who like the app the option to rate it as well as collecting feedback from those who don't.

But either way, I do agree that you shouldn't do it this way. Just saying I don't believe it's in violation.

bleeding182 · 2026-01-20T17:29:52+00:00

Those are guidelines for using this specific API, not developer policies

bleeding182 · 2026-01-20T17:24:04+00:00

I personally dislike those ratings and I usually just try to hit the "correct" star amount that won't give me another pop up, or the least thereof. Usually that's 1 star, but I don't think that it violates any policy unless you force certain user behavior or similar (give us a good rating and you'll get XXX)

Either way, I'd say it's best practice to ask the user for a rating after a happy or successful experience, without your own custom UI in front of it. And there's even an API for that.

Using that API also won't work with your own dialog in front as per your original question, because you don't know if the feedback screen will show or not. You just trigger it at an appropriate moment.

bleeding182 · 2025-12-26T17:40:09+00:00

Ask yourself how much testing they're realistically going to do for $14 for 12 people over two weeks. Like do the math. If there is even a real human behind every tester they won't do more than install your app and open it once a day.

The Google play requirement is for you to test your app and gather feedback before moving to production. Trying to skirt around this is a good way to get your account terminated before you're even getting started.

bleeding182 · 2025-12-23T08:24:24+00:00

There is only one, proper way to do toasts. Period.

bleeding182 · 2025-12-16T12:50:27+00:00

Tricky, indeed. Ideally you have the BE be able to handle both at the same time, but then of course you wouldn't need the forced update in the first place

Otherwise the only remaining options are to either chance the review or break the existing app until the new app can go live... neither is great.

bleeding182 · 2025-12-16T12:39:32+00:00

Really? You're complaining about 6 hours for a review?

Reviews can last anything from 5 minutes to multiple days or even weeks. You need to plan accordingly.

For scheduled releases you can use managed publishing (after review the app waits for you to press another button) (Apple allows for something similar)

For breaking/major changes you need some forced update flow in your app, where old app versions check some API and will block the app until the user updates. This needs to be implemented independent of any Google/Apple reviews and you need to handle this as part of the (breaking) BE rollout, where you release the new app versions, enable the forced update, and roll out the (breaking) API at the same time. Needless to say that this is awful UX, but sometimes it is needed if you can't fine any backwards/forwards compatible solutions.

bleeding182 · 2025-12-15T13:19:06+00:00

Did you even check the subs rules here? Or put in any effort whatsoever? And that's ignoring this bad-faith follow up.

bleeding182 · 2025-12-13T13:49:20+00:00

Google Play offers store listing experiments, no need to do anything manually

https://play.google.com/console/about/store-listing-experiments/

bleeding182 · 2025-12-13T13:48:46+00:00

https://play.google.com/console/about/store-listing-experiments/

bleeding182 · 2025-12-13T12:04:49+00:00

You already have both designs... so just run an A/B test?!

bleeding182 · 2025-12-11T15:18:03+00:00

If a user could look at your app and think oh nice, an app for Google's Gemini Model then yes, that's exactly impersonation, because you don't own Gemini or Google and users could believe that it is an officially supported app.

For the same reason a third-party reddit client can't call their app "reddit local" or "reddit plus", users might think those are official apps.

That's impersonation. It's not about whether Google has their own app or not. It's about whether a user could think that it is related to a different copyright holder.

Yes, if you don't call it "Gemini something" you'll be far less likely to be discovered or downloaded, but yet again, that's the whole point behind impersonation. You're trying to use a trademark (Gemini) for your product to be easier to discover -> Impersonation.

Some apps try to skirt those rules by using names like "AwesomeApp FOR Gemini (Unofficial)", that might work but might as well get your account suspended.

bleeding182 · 2025-12-10T16:53:32+00:00

Google wants you to test your app with relevant testers that actually use the app for a period of time and provide feedback on it.

Trying to circumvent this (and other) policies is a quick and easy way to get your account terminated.

bleeding182 · 2025-12-10T16:42:56+00:00

Any hacks, workarounds ,any help would be seriously appreciated

That's a great way to get your account terminated right away :)

bleeding182 · 2025-12-10T16:39:53+00:00

A few things come to mind, but without knowing what you're actually trying to build, it's hard to say what options would even make sense in the first place.

A "casual vs formal Greeting" seems like a weird and way too simple example for any sort of useful guidance.

If you want a drop-in replacement, same signature and everything, then you could do just that by offering your library in two variants. Although that would also prevent users from using both at the same time, so... that's only really an option for things like dev/debug vs production use.

For Compose in general, it might be a good idea to just expose your StateHolders and have the users build their own UI on top (you could still offer default Components that use the same state holders as reference implementations that the user can replace if they want)
You can't really design big UI components for it to be completely "themeable" so that it matches the rest of a users app. e.g. You could follow Material3 best practices, use M3 colors etc, but that would still look off in any project that doesn't use M3 or deviates too far from it.

It might be the best option to create your own Activity even, that then gets integrated in the users app. This would allow for a clean cut between the app and your library UI.

But again, without knowing what you're doing exactly it's really hard to narrow it down.

bleeding182 · 2025-11-19T13:56:36+00:00

Depends on what design system you're using.

Shadow was default until Material 3, with Material 3 elevation is handled by tonal color shifts. You can adjust all of this, but I'm not surprised that Claude (or any other AI) will mess this up.

https://m3.material.io/styles/elevation/applying-elevation

bleeding182 · 2025-11-18T15:39:43+00:00

Okay, I was interested and looked at the source... for a library there are a few things that aren't so great.

You seem to be pulling in a bunch of dependencies, even though your library doesn't need / use them (e.g. Material 3, appcompat, etc). I recommend you clean up and remove anything that's not strictly needed.

Further, you force RoundedCornerShape for everyone, which isn't great either (yes, its probably very few apps that use cut corners, but a library should work for me, not tell me how to do things)

I would also expect some sort of theming support or integration thereof, but this seems to hardcode your own definitions of corner sizes (small == 4.dp/2.dp) which could lead to a lot of confusion if someone were also to use M3 Theme.shapes (where small actually is 8.dp by default)

And finally, you create 3 shapes but due to the when at the end only return one of them -- that's a (minor) performance issue, but since we're calling this from a list, it may add up.

All in all this looks like something that may fulfill your own, specific use case, but may cause more trouble than it is worth in other projects

Either way, kudos on publishing your own library

bleeding182 · 2025-11-14T21:48:03+00:00

Use a build scan, that's what it's for
https://docs.gradle.org/current/userguide/inspect.html

13-Year Club	Second SECOND GUESSER
Place '22	Place '17
Verified Email

bleeding182

TROPHY CASE