I am new to react-native, and I am going to develop an application by using third-party library called react-native-maps. Currently, everything just working find with online map as this third-party library is used google map. But my problem is went I move to offline mode it would be caused a problem for my application.
My question is there any possible way to make google maps downloaded/cached when the application is load with the specific bound area of a country?
Thank you in advance.
As far as I am aware there is not a way to use the react-native provided MapView to cache the map data. At this time the only offline react-native module that supports offline mapping is react-native-mapbox-gl. I have used it in one of my projects and it is fairly simple to get up and running. The biggest issue with this project is it is still very pre v1.0 in terms of bugs. For basic cases it gets the job done.
Another project I have found has a lot of great features and has a snapshot function that I think could be used to mimic an offline map. I have not tried this but I am evaluating it at this time. react-native-maps
It would function as such:
The app can set aside a cache of a maximum size.
As the app requests tiles, these are cached to local storage.
There is an interface on the map object that enables you to cache a particular tile in the map at a particular zoom level.
The app periodically scans the cache and deletes items in LRU order until it gets under the maximum cache size.
Let me know if the maintainers would accept a pull request like this and I can work on it.
Related
I am setting up a DTAP environment for Google App Maker. Google App Maker enables working in a singe file very well, however there is one use case that I would like to simplify.
For each deployment I need to "know" certain things in the back end script. Things like the ip address of the SQL server, or usernames and passwords. This information needs to be retrieved fast and often, given the stateless nature of google.script.run.
The best solution so far is a settings form, combined with google drive tables and caching. This works, but it is not simple, and things could fail easily. The other approach is hard coded and linked to the deployment url. This is fast and simple, but also means that all the credentials are in the source.
I am looking for a better solution. Apps Script used to have the script properties. Is there a similar option in App Maker, with a UI to maintain the settings.
There is no built-in UI to manage script properties, but App Maker's runtime (Apps Script) provides API to perform CRUD operations on it:
PropertiesService.getScriptProperties().setProperty('testKey', 'testValue');
...and you can 'easily' build the UI on top of this API. In answer for this question are highlighted major steps to achieve this: Google App Maker how to create Data Source from Google Contacts
Here is a feature request for the first party support. You can up-vote it by giving it a star:
https://issuetracker.google.com/issues/73584947
I am looking into using firebase dynamic links in my application. I have a need for passing a unique identifier into a users application from an email-generated link. This works fine when the user has the app installed, however, I am running into some confusion with how the application is not installed.
I see that firebase dynamic links has support for taking the user to the app-store if the user does not have the application installed. They then use (deferred?) linking to take the user into the deep-linked target of the app after the application is installed. How is this done? How is a match guaranteed? Or is it?
Branch.io has significant documentation and this on how they handle deferred deep-linking accompanied by all of the strategies and fallbacks that they implement. Do firebase dynamic links rely on the same strategies or do they have another mechanism to 100% guarantee matching of a user from deep-link through app install and into app open?
Alex from Branch.io here:
Firebase uses simplistic device matching. This means matches cannot be 100% guaranteed, because there's always a chance that two devices will look the same to the Firebase backend. Until recently, the system-wide Dynamic Link attribution window was only 5 minutes, to minimize this risk.
This is a relatively minor issue if you're not passing sensitive/personal data through using links, but if you are then you might want to consider using Branch as a drop-in replacement. It's fairly easy to do.
I am working on Meteor app(e-commerce site), became very large. It almost takes 9secs to view static part of homepage till then it only shows white/blank screen. After that it starts showing data from DB(mongoDB). The whole site with data takes ~24secs to come at client side. I think the whole bundle is too much huge and that is why it takes more time to download. And it is causing 9secs of white screen. Any solution guys. Thanks in advance!
Alraedy Tried:
1. Fast Render(Flowrouter subscriptions) package
2. Appcache package
3. Query Optimization/Indexing
4. Removed global subscriptions
5. Sending minimal data via pub/sub
6. this.unblock() for publications
7. Not saving files in DB instead saving url's
You are working on an e-commerce website and so you might have a huge admin module bundled with your website. You should consider building the admin module as a separate Meteor app sharing the same Mongo DB collections with the e-commerce website. You can reduce the size of you app considerably using this approach. You can find more details here
You should also be really careful about your subscriptions and use pagination on the server side publications, subscribing to only what data is actually required
For starters, try to remove unused packages which aren't used anymore by any frontend code. Check your entire package.json and all imports.
Reduce the size of all you subscriptions, you probably have tons of them with entire or too big documents, which is easy while developing, but an overkill in production. Try to limit the fields and the amount of loaded objects to what you visualise for the user.
Don't wait for all subscriptions to finsih loading before showing something, load the website and it's design already, but only show a 'loading' icon on the parts that do require data to be shown dynamically.
Make sure your javascript is minified before it's published, this saves a lot of bandwidth.
After implementing these your load times should have decreased.
Providing a detailed network analytic from the debugger of your browser might also help to notcie problems.
I was thinking of making an app which plays a specific set of small audio files stored away in a firebase database, or any other database on the cloud.
The number of files may exceed hundreds, so wrapping all the files in the app might not be the best of ideas.
I'd really like to know how to go about this problem.
Downloading only the required file from firebase when it's clicked and playing as its being downloaded all the while caching it for future playback seems plausible, but I'm not quite sure how to implement it.
I'd appreciate a few pointers towards this, thanks
Yes. You are thinking in the right direction.
You might use these things.
App UI - Ionic2 will provide you a very nice and easy to implement platform to create a UI. Please refer this documentation for the basics and details about using Ionic2.
Local Storage - You can use this to store downloaded files. In any app where data is relatively large, using local storage is the smart choice. This helps you reducing the size of the initial app to be installed and download the content as and when needed.
A well defined database - Now, whether to use non-structured (No-SQL) or structured (SQL) is the first choice you have to make.
If it's just content - audio files download and play with no complex cross querying the database, then you can choose to use non-structured (No-SQL) database like Firebase database.
But, if you have good requirements for structuring data, query it with constraints like "Give me all the audio files list where a particular user has played it in last 10 days" or "Give me all the users who has played/downloaded a particular audio file more than 10 times" and so on, then you better use structured (SQL) database like PostgreSQL.
RxJS - Now, this might not be very important to do, but, if you use this from the start, it's a good choice. Advantages are, e.g. you might not have to wait for all the file to get downloaded before playing it. Use Observables and Promises for such a mechanism.
Could help with the specifics when needed. Hope this helps. :)
I wanted to know which one is easier to implement. In the branch app indexing method is it required to implement app content sitemaps?
Full disclosure: I'm the Branch.io team
The way Firebase and Branch implement app indexing is fairly similar. In fact, Branch uses exactly the same methods for indexing as Firebase does, and adds some additional functionality on top. Branch acts as a wrapper for your own website, or as your full hosted website from the perspective of Firebase. So, when it comes to indexing with Google, you index a Branch link whereas Firebase requires you to submit your own site.
From the perspective of a developer, assuming the only thing you're trying to do is app indexing, Branch is slightly simpler to use and gives you rich analytics about the traffic from this channel but neither one is a lot of work. However, both platforms also provide other features that may sway your decision. If you're doing any sort of content sharing (i.e., your users create links to post on social media), Branch gives you app indexing basically 'for free' in the same library, whereas Firebase would require you to implement both features separately.
Both tools are free to use.
Firebase
Offers a lot of features (of which app indexing is just one), all implemented to a 'fairly good' level. This makes the Firebase platform an attractive choice for a small, new app that needs a lot of basic infrastructure and doesn't necessarily plan to require advanced functionality later on.
On Firebase, App Indexing for Android apps is implemented via integrating the Firebase App Indexing SDK and making a verified link between your website and your app (usually via Digital Asset Links or the Google Search Console). The 'Firebase App Indexing' SDK is actually just Google's old App Indexing SDK that's been rebranded and repackaged in a peculiar way.
You then register content items inside your app using the SDK and cross your fingers in hopes that Google will index them — there's no feedback on the process. App Indexing for iOS apps is based on crawling URLs that have been enabled for Apple's Universal Links. There is a Firebase App Indexing SDK for iOS, but to be honest I have no idea what it does. We've never seen any benefit or change to indexing behavior on iOS when it's integrated. On both platforms, you need to already have a live website, because every piece of content inside your app must also correspond to a specific URL on your site.
Branch
A best-in-class, enterprise-grade tool for growth attribution and content sharing, used by many of top apps like Pinterest, Airbnb, Jet.com, etc.
Branch is based around the concept of a single link that works everywhere, on all platforms, and intelligently redirects to the appropriate destination. Every time your users share content or view a piece of content in your app, that action generates a link. Since Google's search index is really just a huge collection of links, this is a perfect match.
On both Android and iOS, Branch de-dupes your app's links for any that point to the same content, packages up the result into an 'app content sitemap' (you don't have to do this yourself if you're using Branch links — it's automatic as soon as you enable the feature) and ships that sitemap file over to Google. In addition, since your links are hosted by Branch, there is no need for you to have an existing website, and you also get access to things like iOS Spotlight Indexing. Branch is compatible with iOS Universal Links by default, and we take care of verifying the connection between your web content and your app. We also monitor the links so we can give you feedback on if/when Google decides to index your content, and so that you can pull out reports on traffic that comes in through app indexed links.
On Android, in addition to the approach above, the Branch SDK helps you to identify pieces of content inside your app and submit them to Google for indexing. This is exactly the same approach as Firebase uses, except since the traffic still goes through a Branch link, you get additional data for attribution and analytics.
Feel free to read the full Branch Google App Indexing integration guide for more details!
Of course, implied in all of this is the assumption Google actually cares about your content enough to display it in search results. They seem to be getting better about this, but at the moment it's still very much a black box without much feedback to you as the developer. At Branch, we're trying to provide as much insight into the process as we can, so at least if your content isn't being indexed by Google you'll know that instead of being left wondering.