Java package names are supposed to be inverse domains (google.com turns into com.google), so it’s a bit strange that slickapp.co doesn’t use co.slickapp, unless they also own com.slickapp.
Of course there’s no real enforcement here, you could just name your package my.roommate.steve.is.kind.of.a.dick if you wanted to.
Android apps can declare which urls they accept as deep links. Once that is registered with the system (ie after install) then links of that type can be opened by the app. It doesn’t have to match the package name.
Their website is slickapp.co (without the m at the end), but their Android package name is com.slickapp.
Isn’t that a bit of an issue?
For example, when handling URLs?
Don’t most Android packages begin with com. ?
Java package names are supposed to be inverse domains (google.com turns into com.google), so it’s a bit strange that slickapp.co doesn’t use co.slickapp, unless they also own com.slickapp.
Of course there’s no real enforcement here, you could just name your package my.roommate.steve.is.kind.of.a.dick if you wanted to.
@biscat @tanja yea
that’s just name-spacing android apps. They all have a certain unique identification string.
Not really.
Android apps can declare which urls they accept as deep links. Once that is registered with the system (ie after install) then links of that type can be opened by the app. It doesn’t have to match the package name.
The package name should, however, match a domain owned by the publisher of the package.
That’s not how android names work at all.
That is how Java names work. The whole domain-like appearance is meant to avoid name collisions between packages made by different companies.
Don’t they all start with
java.
tho? Thereby instantly making it not-a-domain.You are thinking of the standard library, I mean package names for third party code, specifically for what Java calls packages.
https://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html