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.
Related
I have 2 different Play Console accounts and each have a Stories app in them. Currently both of them are linked to same Firebase account (i.e. same database). I want to ask if this is ok or should I make a separate Firebase project for each app?
The short answer is, it depends.
If the two apps are identical or closely related (eg. an admin-only app that controls the flow of the client app), then yes, you'll want to configure both apps to use the same Firebase project so that they both have access to the same data.
Using the same Firebase project in multiple apps is pretty common, especially in the scenario outlined above as well as deploying to multiple platforms. Take, for example, an app that you have deployed on the web, iOS, as well as Android. These apps run on different platforms, but they are essentially the exact same app, with the exact same functionality. You don't want to be maintaining multiple projects containing duplicate data, so it's a good idea to connect different versions of the same app to the same Firebase project.
On the other hand, if these apps are not related at all (eg a quiz game and a social media app), then it doesn't make sense for them to be using the same Firebase project as the two apps are completely separate from one another. In this scenario, using the same project would lead to disorganized data, as well as making it potentially more difficult to secure and query as the apps have separate functions, and thus separate logic to control the flow of data.
It sounds like your use case falls into the first category. You have the same app on multiple Play Console accounts. You probably want the data to remain consistent between them, so you'd want to use a single Firebase project.
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 have updated my app and published the update to Windows App store but during certification it fails by giving below reasons
App Policies: 10.1 Inaccurate Representation Your app and its
associated metadata must accurately and clearly reflect the source,
functionality, and features of your app. All aspects of your app
should accurately describe the functions, features and any important
limitations of your app. Your app may not use a name or icon similar
to that of other apps. Your app may not claim to be to be from a
company, government body, or other entity if you do not have
permission to make that representation. Keywords may not exceed seven
unique terms and should be relevant to your app. Your app must be
fully functional. Locations: Metadata Notes To Developer The app
metadata promotes another mobile platform. For more information see
http://go.microsoft.com/fwlink/?LinkId=615230.
I don't know what happened to this update. Earlier versions were approved without any issue.
If anyone have any clue how to fix it , please please let me know.
Anyway the solution I rebuild and deployed again without any changes and this time it is certified without any issue.
Don't know what Microsoft was looking for.
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.
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.