-
-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Android Annotations proposal #1255
Conversation
@fynngodau Thanks for bringing up this proposal! I went through it today and liked the direction it takes a lot. From what I understand the old workflow of adding annotations via the manager would still co-exists, right? That's important for us in our library as we currently make use of it. What I like a lot are all the options that can be used to fine-tune the appearance of the elements, e.g. Padding, Transform, ... |
@RomanBapst Your library sounds very exciting!
Yes, this is what I had in mind. It would be necessary to create annotations using the changed API, but they could still be added to annotation managers as previously. As explained in the proposal, the two use main cases are
|
As a general note, while porting cycle.travel's app from iOS to Android, I've been surprised how different the Android and iOS APIs are. Obviously each platform has its own design patterns (e.g. iOS delegates, Android builders, etc.) so you wouldn't expect full convergence, but there's a lot that seems needlessly different between the two - annotations being just one example. It means a whole bunch of extra cognitive load when porting or developing in parallel. From looking through issues on the old Mapbox repos it looks like their two teams were working independently. So perhaps an additional design goal would be appropriate: increased commonality with MapLibre iOS Native. That doesn't necessarily imply changes have to be made here in Androidland - it could equally mean changing the iOS API to match the new, better Android API. But I think it's worth considering as an aim. |
@systemed Very interesting point! Now that Swift is the language of choice for iOS development, I think it makes sense to offer a better Swift-first API in the future. Being a much more modern programming language with quite powerful features (in comparison to Objective-C), I think a lot is possible there. If you have specific ideas in mind or want to contribute, check out the general topic for iOS modernization #1248. I gave you a follow in LinkedIn, let me know if you ever want to brainstorm about this. |
Cheers! Swift and Kotlin are broadly similar languages, each with a good async/await story and heavy use of blocks/closures. To my mind this gives the opportunity to remove some of the more idiomatic design patterns (Java-ish managers and builders, ObjC-ish delegates) and converge on a simpler, more direct API. So @fynngodau's suggestion of de-emphasising manager objects makes a lot of sense in this context. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Disregard my earlier comment, I think it is better to use maplibre-native
since you are referring to the repo, not the project.
LGTM!
Fixes #1189 by planning a new and improved annotations API for Android.
Latest version for reading: https://github.com/fynngodau/maplibre-native/blob/annotations-proposal/design-proposals/2023-06-17-android-annotations.md