search

CartoDB / mobile-sdk

CARTO Mobile SDK core project
https://carto.com/docs/carto-engine/mobile-sdk/
BSD 3-Clause "New" or "Revised" License
187 stars 68 forks source link

Enable online update of styles #119

Closed jaakla closed 6 years ago

jaakla commented 7 years ago

Need to consider many aspects here:

This is placeholder issue, for details see Feature doc

jatorre commented 7 years ago

My point in here:

Our mobile SDK supports by default 4-8 styles that we maintain. Those styles live together with the server of vector tiles and are alwasy updated to work with the current schema we are providing.

If the schema changes, our published styles on the web will also be updated if they need to.

Mobile SDK applications when loading a map "voyager" for example, first retrieves the style, which includes info about the sources too, and then starts making requests to the source.

The Mobile SDK can provide a set of options to customize the view, like the list of params we said to have for our own styling of raster and on the web, and the developer have the possibility to override those parameter programatically.

If the developer decides to use an entirely different style created by him he is under risk that in the future the schema changes will break it and is its reponsability to keep it updated.

On offline. When downloading an offline package ideally the style associated with it is also downloaded, which matches the package that has been downloaded. The further customizations still apply like before.

jaakla commented 7 years ago

The key issue with loading online styles is that we cannot show map at all without style, but users expect immediate maps and they do not have fast enough bandwidth to download styles before maps. Style packages can be easily quite big - current minimal is few megabytes as minimum, and can be tens of megabytes due to the bundled resources (e.g. international fonts). Mapbox has to download 50-80MB style resources before they can download single real map tile offline, and this is terrible; do not want to repeat the mistake of adding offline support as afterthought.

The biggest specific challenge in vector map styling is to have fonts (full international fontsets can go to hundreds of MB), as we cannot use device system fonts due to platform API restrictions. Now once we have some key fontset bundled with SDK, then maybe can have quick enough style loading + lazy additional custom font loading approach. Especially if we can limit at least ourselves to small number of used fonts.

Once big font/resource challenge is resolved, then core style css/xml with colors, rules etc is quite small and we can load at least our small set of styles on-demand as you suggest.

jatorre commented 7 years ago

Can it be that our Mobile SDK bundless the assets so it is part of the download of the app? At some point those MB need to be downloaded.

We dont need to have all fonts in the world avsailable, just a few that works well... so dont see, similar to what we are saying with a few pre-defined styles than can only be modified with parameters, I dont see why we can not bundle a few fonts with international support that are what they can be used straight away.

CARTO http://carto.com - Turn Location Data Into Business Outcomes Request a DEMO now https://carto.com/request-live-demo/ to learn how we can help you with your location data

On Wed, Jul 19, 2017 at 4:35 PM, Jaak Laineste notifications@github.com wrote:

The key issue with loading online styles is that we cannot show map at all without style, but users expect immediate maps and they do not have fast enough bandwidth to download styles before maps. Style packages can be easily quite big - current minimal is few megabytes as minimum, and can be tens of megabytes due to the bundled resources (e.g. international fonts). Mapbox has to download 50-80MB style resources before they can download single real map tile offline, and this is terrible; do not want to repeat the mistake of adding offline support as afterthought.

The biggest specific challenge in vector map styling is to have fonts (full international fontsets can go to hundreds of MB), as we cannot use device system fonts due to platform API restrictions. Now once we have some key fontset bundled with SDK, then maybe can have quick enough style loading + lazy additional custom font loading approach. Especially if we can limit at least ourselves to small number of used fonts.

Once big font/resource challenge is resolved, then core style css/xml with colors, rules etc is quite small and we can load at least our small set of styles on-demand as you suggest.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/CartoDB/mobile-sdk/issues/119#issuecomment-316508847, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHzOxLMMVKnP8cC6lB06W1P-Y16FqNcks5sPmh-gaJpZM4Ocgd5 .

jaakla commented 7 years ago

Yes, bundling as much fonts as we can is what I meant also. Full international set is big, so far have got smallest package (one font covering all countries with official languages) to about 5MB. Compared to SDK binary itself (about 4MB) it would more than double SDK, and some developers are very sensitive about it, as they want to keep whole app install in Android below 10MB limit.

Another challenge is that inside SDK APIs and classes for data and styles are independent by design, adding coordinated versioning solution there involves changing many pieces, see drawing in the feature doc (link is above). It can, and should be done, just needs some detailed design.

jaakla commented 7 years ago

@mtehver - updated feature doc. Next steps:

mtehver commented 7 years ago

The script to generate 'files' section in style.json is under mobile-styles repository (tools folder). SDK in develop branch is now updated to support online style updates according to the design doc.

jaakla commented 7 years ago

Server-side http://api.nutiteq.com/styles/carto.streets/v1/voyager.json works now, files are in Azure Storage really.

jaakla commented 7 years ago

Note that in this implementation custom (new) styles cannot be added, only SDK built-in styles (3 styles) can. So to add new styles also SDK needs small code change, app will need SDK update, and then can add new styles. This should be ok, as the apps could not use new styles without app code update anyway. This can be added when there is real life requirement for it.