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.
Related
I've looked around for answers to my question, but most are actively trying to do what I don't want which is why I'm asking.
An app I'm developing for the company I work for has gone live, and so to further develop I need to use Firebase preview channels.
I've looked over the documentation and it states that channels use the same resources, which I find a little unclear.
Does this mean that preview channels are UI only and using an app on a preview channel will still write to the live database (Firestore) that customers are currently using?
If you're talking about Firebase Hosting preview channels, the only difference between each channel is the web content (html, css, js, images) that you deploy to it. The configurations for the other Firebase products (database, analytics, etc) don't change at all. You can see this for yourself by printing the active Firebase configuration in JavaScript - you should see the all the same values.
If you want to build against a different database before you push updates to production, you should instead use completely different Firebase projects to keep them separate. It's common for developers to keep multiple projects for multiple environments, such as development, staging, and production. This is the formal recommendation.
Bottom line: A Firebase Hosting preview channel just lets you try out different web assets against the same backend services. If you want different working environments to avoid disturbing customers in production, you should use different projects entirely.
We about to build a mobile app which displays static content made up of text, images and videos. For what it’s worth, it’s a social enterprise in the field of mental health.
We want the content displayed in the app to be driven by a CMS, so that it is easy to collaborate and update the content without needing to release an app update. Normally I would just set up something like Django and expose the content via some REST endpoints.
However we’re keen to build a really great offline app experience, so the app is going to need a cache of this content one way or another.
I’ve been looking at Realm, Firestore and AppSync which all seem brilliant in many ways, but I’m wondering whether they are overkill for something like this, as really what we need is just uni-directional sync, not the bi-directional magic they provide. I’m also slightly nervous about using something that isn’t as mainstream as REST (we once built something using Parse.. before Facebook shut it down).
My question is therefore are there any simple, widely used, reliable technologies or design patterns which solve the problem of syncing a cloud CMS into a mobile app data store
?
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.
So Firebase has these Dynamic links, which if you click in your Android / iPhone you get redirected to your app instead of the website. So when you want to invite your friends to join you in the app (game, group chat or whatever) you just share this link with them.
I was wondering if this was achievable with UWP. I watched a video about project Rome where they talk about AppUriHandlers which seem to do the job. HOWEVER they require you to have a json file at your web server root which would identify your app, saying "yea, this app is allowed and me are associated, open this app when someone launches this link".
The problem with that is that the Firebase dynamic link points to a google endpoint, e.g. https://aaxy2.app.goo.gl/?link=redirect_here and naturely there is going to be no json file just sitting there.
Is there some other way how to have users redirected to my app just via a link (it needs to be an http link because that's what the Android and iOS versions of the app will be using).
It's not going to be possible; for this exact reason. To ensure that web links aren't hijacked by third parties (for potentially malicious reasons), only the owner of a domain (or more accurately: the person/people with access to the storage where the domains points) can "approve" an app.
Update:
After actually doing my job and properly reading your question, I can give you a correct answer; sorry :/
Linking to UWP apps will work similarly to how it's described for iOS apps in the first section here:
You can do the iOS 8 way and support a uri scheme as described in the Windows docs here.
With the Anniversary Update you can also support AppUriHandlers by directing your users to a web link that will launch your app instead (as described in the Dynamic Links docs for iOS 9).
It looks like, however, that you need to register an iOS or Android app to get going, so that might give you some trouble.
Short Version (tl;dr):
Is there an open source or commercial engine that provides embeddable collaboration and microblogging functionality?
Long Version:
I am creating a niche application that has need of this functionality and do not want to reinvent the wheel. The following are must have requirements:
Data API only. My application is SaaS, and I want to build the functionality around the data. This eliminates most of the offerings out there (facebook, salesforce chatter, yammer, present.ly, teambox)
Does not require use of a built-in front end. I really just want an engine that will take care of the storage and events, and gives me a means of querying. Requiring the use of a specific front end renders it useless for embedding into my app. This eliminates everything else I have found (status.net, Yonkly, Jaiku)
Beyond standard updates and replies, can handle custom events. For example, if I were embedding this into an logistics application, I could have the engine handle events like "shipped", "received", and "cancelled".
Beyond this, there are several nice to have features that a framework would have:
Should not require a specific platform or server technology to run (i.e. something like a RESTful API would be nice)
Should be message based so that commands that affect its state can come from any source
Should encapsulate its own storage so that external resources are not necessary (i.e. no database needed)
Should have pluggable extendable UI components/widgets for web, mobile, and desktop clients
Should have search and retrieval APIs available for many languages/platforms
It seems that someone out there should have this already, or at least be in progress with it. Please point me in the right direction.
Since nobody had any answers and continued research did not find anything, I created a solution on my own called Collabinate. Updates can be found on Twitter, and the project itself is hosted on GitHub.