How to fetch device information (Google Advertising Id or IDFA) from a progressive web app
https://developers.google.com/web/progressive-web-apps/
Google Advertising ID is not accessible to progressive web app running in browser and so the installed PWA.
Said that, you can make it available to your installed PWA using an Android service(which is a native code getting the Google Advertising ID) and passing it to your PWA using Deep links, by setting a Indent filter to your PWA with a URL and have the ID retrieved in your native code passed to web app in the query para (URL).
You can refer to this java code to retrieve device identifiers and wrap it as a Android service, which calls your PWA using deep links.
Related
I am developing an application using Supabase, Flutter and Google OAuth and I would like to know if it is possible to have a single clientId and clientSecret for each device type (ios, android and web) so that I don't have to implement a different authentication workflow for each device.
I have tried looking around the Google Console and see if it is possible to create a single authentication API for multiple devices. I also tried searching online.
There are sevral types of Oauth2 clients.
installed app client (for applications run on the machine)
web app clients (for applications run on web servers)
Android app clients (for applications run on android devices)
IOS app clients (for applications run on Iosdevices)
The authorization method for these three types is different, the code used to authorize them is also different. They can not be mixed.
Android app requires SHA-1 certificate fingerprint
Ios app requires App Store ID
web app requires a redirect uri
So the answer is no you can not create one type of credential to work with Android, Ios and web, you need three different credential types.
a bit of sdk magic
If a user authorizes your web app, they may not need to authorize your android and Ios apps as long as the credentials are all part of the same project on Google developer console.
Last I checked this is not true the other way around, if a user authorizes android or ios first and then tries web they will need to authorize again.
My guess is this is something baked into the android and ios sdk on googles side that is not part of the respective client libraries for web. Either that or its something in the authorization code grant that isn't in the mobile code grant type for Oauth2 I have never bothered to dig to far into it.
My project requires video call using flutter (mobile) and native web. When using the temp token generated from the console both web and mobile receive video and audio. When using the token generated from my server the mobile app receives the video feed from the web but the web does get any feed from the mobile app.
However on the app work fine when connecting mobile app to another mobile app.
flutter 2.2
agora_rtc_engine: ^4.0.6
Fixed
The problem happens when the UID on the mobile and the web are not the same data type. I was using local storage to save the UID local. The issue with that was it was retrieving the UID as a string not int. Resolved the issue by converting the UID to int when retrieving it from local storage.
Flutter Web is not currently supported by agora. There is an alpha release for web support, but since it's not official, it could be buggy.
https://pub.dev/packages/agora_rtc_engine/versions/4.1.0-alpha.2
I'm looking to launch a single web app that works as a PWA for web users and a TWA for users wanting to download it from the Google Play Store. The app includes a yearly subscription so I'll need to implement separate payments methods for the PWA and TWA in order to comply with Google Play policies.
With this being said, is there a way to identify with JS if the user is viewing the PWA vs the TWA app from the play store? Perhaps something unique to check in the global window object?
Or, is it recommended to publish a whole new version of the app used for the TWA to a different URL that only supports the Google Play payment option.
Any info would be great. Thanks in advance.
I want to develop native mobile application in which user will send invitation to his friend to install another companion native application via a link to the application. But in order for this to work I need to pass a custom token or parameters in the link so that when the companion application is installed by the user's friend, this token is parsed by the companion application to display personalized message ( much like query string parameters are passed in the URL for normal web applications). Is this possible for iPhone and Android native applications?
It is not possible on stock iPhone/iOS devices. App installation on iOS devices can only be done through the App Store app or iTunes, which do not accept any additional parameters other than the app identifier in the URLs they handle.
I want to access TTS (Text-To-Speech) and STT (Speech-To-Text) functionality of iOS from web app. Since web app dont access ios device functions, is it possible to launch Native app from Web app?
e.g. When user wants to access TTS (e.g. Dragon Dictation), web page will launch Native app, take recording and send the recorded text to web app again.
Or we can access TTS/STT functionality right from web app?
The only native apps you can access from web apps are those with custom URL schemes set up, and the built-in ones e.g. SMS (sms://), phone (tel://), iTunes (itms://) and YouTube (http://youtube.com/watch?...).
If the apps you mention don't have their own custom URL schemes which you can use to get to them, there's no other way you can do this.
I can answer one part of your question - using the functionality of an IOS native app from a web-app;
Apps can be developed such that they respond to custom URL schemes - like, for example, the mail app responds to mailto:// and youtube responds to youtube://. Calling a URL with one of these schemes will start the IOS app - but it's entirely on the developer to code this into their application.
You could therefore in theory develop an app to get triggered from a web-app, perform an action then return to a web app after! Probably not something I would try and do though.