I want to use pubsub's pull subscription.
So far its been hard to figure out setting auth & fails in subscription or grpc.
Also its not recommended to package client-secret.json in apk.
Havent found any leads to setup on android
Has anyone done this on android
On the Setup client library its mentioned
Note: Cloud Java client libraries do not currently support Android.
Following this link for Pull Subscriber
Any help would be appreciated
Pub/sub to a mobile platform has some potential issues, depending on your use-case. For example, if a phone is off for a long time, pub/sub will queue a lot of messages which may be expensive. You also would need to create a topic for every user if you want to keep data for each user private.
You might find that Firebase Cloud Messaging is a better solution for pushing notifications to an android app.
Although the com.google.cloud.pubsub library doesn't support Android, the com.google.api.services.pubsub library does. com.google.api.services.pubsub is auto-generated, so is harder to use and worse documented, but it should work on Android.
See client libraries explained for the difference between the libraries.
Related
Background
I was recently tasked to work on an SDK that Android developers could use via simple dependency (got this working for Jitpack&Github, here).
One of the tasks I was given is to use Firebase for remote-config and Analytics (and maybe Crashlytics too), to be able to gather statistics and have some control of it using the cloud.
The problem
All tutorials, articles and documentations (example here) that I see of Firebase are for Android apps, and so the preparation itself requires a package-name of the app to be set.
This is impossible for an Android library that is supposed to be used as an SDK, as it's meant for many apps, each has its own package name.
What I've tried
I tried to ask Firebase support about this, but they told me they can only talk about Android apps, and gave me a Github link (here), probably hoping I could get something out of it.
I also tried to ask on reddit (here), but nobody knew the answer to this.
Looking at the list of available, official SDKs (here), I think such a thing might be possible if I register as if it's a website (or web-application), and then in code I would reach it as a website (using REST API on Retrofit), but not sure if there is a better way, whether it will work, and whether it's even according to the rules of using Firebase (I think should be ok).
There might be a way to use the C++ library that Firebase offers, too, but this would probably require a lot of adjustments.
Seeing that this might not be offered natively, I even made a request about it., here.
The questions
Is it possible to use Firebase inside Android libraries? As an SDK? Is it according to the rules of Firebase?
How do I do it? Is there perhaps a library for this? Maybe a general Java library ? I guess I should also be able to make it focus on my SDK's classes and functions, and ignore what's on the app itself.
If there is no library, where can I find the various functions that are available for the various services, so that I would implement them?
I've been looking for a way to send push notifications to Android, iOS and Windows phone devices. I've come across the Parse4cn1 library. This library uses Parse. However i saw on the Parse site that they will retire soon. I have the following questions regarding the Parse4cn1 library and the retirement of Parse.
Does the Parse4cn1 library still work after Parse's retirement?
Do i need to setup my own open source Parse server to support the push notifications and when i do this does it also support push notifications for Windows Phone? (http://blog.parse.com/announcements/parse-server-push-notifications/ says it doesn't but i'm not entirely sure.)
Kind regards,
R Visser
See this related SO question.
In any case, parse4cn1 will not support features that are not available in Parse Server. As far as I know, push is currently only supported for Android and iOS by Parse Server. So when parse4cn1 is updated, it will support those. However, I've not scheduled that update yet. Feel free to chip in if you have the time/resources to update the library and issue a pull request. I'll be glad to review and merge it.
By the way, I recently came across OneSignal which claims to offer free push notification on a wide range of platforms. I have my reservations though as they apparently sell your data and unspecified device info to third parties in return for the free push services. I'm yet to do a full evaluation so don't take my word for it. Have a look yourself and decide if it's interesting to you.
I hope this helps.
I am newer to Android but am trying to add a chat feature within my application. In terms of areas I have tried they include pre-built systems such as Quickblox and Scringo, but each are highly inflexible and also require employing their user authentication sources as well, which are not needed.
Is there a general location for resources to build a chat feature that will also persist past messages for viewing as well? Or suggested services that could help handle sending messages?
(Any guidance is greatly appreciated)
I've been reading through developers.google for a few days now and this process is still confusing me.
As far as I can tell, I need the following:
An Android application
A Java App-Engine backend that uses Endpoints (still not quite
understanding what these are).
Code within this backend that connects to my Cloud SQL instance.
My problem is that none of Google's examples seem to have an Android/Cloud-SQL example.
I've been using this guide on how to create an Android app with App Engine backend. But then it uses Google datastore stuff, I think? I need to use SQL rather than this.
In this guide there is mention of App Engine, but for a JSP web form front-end, and no mention of Endpoints.
So my questions boils down to, have I got the right idea with using EndPoints + Cloud SQL, and if yes, how does one achieve this? I'm quite a JDBC newbie in general, so I'm not quite sure how to achieve this off the top of my head.
you are on the right track.
Just for the record, if you don't have strong reasons (yet) to go for a SQL data store, do consider using Google Data Store as it is better seamlessly integrated into the SDKs and after a couple of compromises it should help you pushing your data design to scale nicer.
Let's split it into parts:
First you have your backend/api. This is basically your piece of code that operates on Google servers, which you'll access on an remote connection basis (http, socket, etc) - (same as most of the APIs we know work). I don't know which programming language you are using but here is some basic set up for your project and Cloud SQL on Python.
Cloud Endpoints is nothing more than a very cool feature that App Engine brought recently to avoid all the mess of creating and updating your client libs over and over again. It basically automates that task for you, by using annotations or references you put in your backend code to create client libraries for Java, Objective-C and JavaScript that you can then integrate into your clients.
Example: Let's say I have a controller on my api to operate with bananas, that has a method to delete a banana from the api. Annotating that method on your api code, will let endpoints script know that this methods is there to delete bananas, thus it'll gather it and include it in the generated clients libraries, so that you don't have to do that manually for any of your clients, nor every time you update you api code. [Here's] some documentation.
Android Application. That's certainly your business :) But I'm sure having your api libs already generated already helps a lot.
Hope it helps. Let me know if you need to get more into detail.
It has been a couple of weeks and I am having so much trouble making C2DM work. I've read a million guides and watched video tutorials but have had no luck. I just need a way to communicate with my server and my phone in the simplest way. Any help?
If you're still interested in trying C2DM, try installing the Google Plugin for Eclipse and use it to generate the Android / App Engine sample project. It should be able to generate a skeleton project that is able to communicate between AppEngine and a basic Android application. You could verify that the sample works and use it as a basis to debug your custom application.
There was also a related AppEngine + Android session at Google I/O this year.
The easiest way to get push into your app is to use a third party push provider like Urban Airship or Xtify. Instead of writing the code to interface with google directly you integrate the third party SDK into your app and they handle the messy stuff.
Additionally, you don't have to worry about scaling if your app gets (or already is) big. And going cross-platform (iOS, Blackberry) is that much easier.