What Does "GADDelayAppMeasurementInit" Delay? - objective-c

When using Google Mobile Ads SDK and integrating User Messaging Platform SDK, Google offers to Delay App Measurement.
You can do this programmatically or by adding GADDelayAppMeasurementInit to the info.plist and setting the Bool to YES.
It states:
Google Mobile Ads SDK initializes app measurement and begins sending
user-level event data to Google immediately when the app starts. ...
However, if your app requires user consent before these events can be
sent, you can delay app measurement...
But what does it actually do? What metrics are delayed? Does this affect whether personalised or non-personalised ads are served after providing consent?
There doesn't appear to be any more information on this anywhere.
Thank you.

Related

Sonos - How to play a Spotify/AppleMusic track on a Sonos device from my iOS app?

I'm integrating the Sonos Control API into an iOS app. In our app:
the user is signed in either to Apple Music or Spotify via an Apple Music subscription or a Spotify premium account.
the user can play Apple Music and Spotify content within our app (we have the track / album IDs and use this to play music via the Spotiy / Apple Music APIs).
the user also has the Sonos app installed, and is logged in to their music service of choice (Spotify or Apple Music).
Now when the user is listening to a track in our app, we'd like the user to be able to listen to it via their Sonos device. Our app is for children and has parental control, so the user needs to stay within in our app.
Is there currently any way to achieve this?
Options we've looked into:
Streaming: As I understand it, there is no way to stream audio to a Sonos device. The AirPlay-Sonos compatibility is not an option as we're targeting all Sonos devices.
Sonos Control API: We then looked into starting the track using the Spotify or Apple Music track ID via the Sonos Control API, but this answer seems to imply that this is not possible. Is this true even if the user is logged in to the Spotify / Apple Music service both in our app and in the Sonos app? For example I could imagine using createSession with a Spotify / Apple Music accountID so that I would have access to these services, and then using loadCloudQueue to load the trackIDs. But I could be misunderstanding the API.
sonos-objc: This looked promising, but is very outdated and we haven't managed to set it up.
Any leads on this would be greatly appreciated.
Thanks!
You are correct, streaming tracks directly to Sonos is not currently supported in our platform. Using music object ids, with their constituent content and account ids, is a vehicle for actual content partners to build direct control integrations with Sonos. iHeart, Pandora, and Tidal have done this for instance.
The reason non-content owners can't utilize this functionality is due to the way authentication is handled. To ensure rights-holders property remains intact, we require partners to execute an account matching flow. This account matching requires direct access to a content partners' auth back end, pretty much limiting these types on integrations to the content partners themselves.
We understand that non-content partners want to put content directly on Sonos, and we're actively looking for the best ways to do that, while still allowing content parters to maintain control of how their content is consumed.

What is a progressive web app in layman's terms?

I have been a dev for some years now, but I can't wrap my head around what exactly is a PWA.
For example, if an app runs on a mobile phone it is a native app. I can point to it and tell people that "look it is a native app."
In a similar sense, what is a PWA? Where does it run? Which app can I point to and tell that it is a PWA?
From what I have read on the web I feel that a PWA is a website that has modern technologies and gives a "native app like" experience to the user.
Is my understanding correct?
All in all, it is a website that has native-like experience?
If so how does a user separate a normal website form a PWA?
The concept of the progressive web app (PWA) was approached by Google in late 2015. They are basically web applications (Website) but have look and feel like other native mobile apps. The progressive web app enabled websites can offer functionalities such as working offline, push notifications, and device hardware access.
Benefits of the progressive web app:
1. Smaller and Faster:
The progressive web apps are much smaller in size than native apps. They don’t even need to install. That’s they are not wasting disc space and load very fast.
2. Responsive Interface:
Progressive web app (PWA) supported web pages are capable to fit in every screen sizes automatically. It could be a smartphone, tablet, desktop or laptop.
3. No Updates Required:
Most of the mobile apps need regular weekly updates. Like the normal website, progressive web apps (PWA) are always loaded latest updated version whenever the user interaction happens and no App or Play Store approval required.
4. Cost Effective:
Native mobile apps need to be developed for both Android and iOS devices separately and their development cost is very high. On the other hand, progressive web apps are had the same features but the fraction of the prior price.
5. SEO Advantage:
Progressive web apps are discoverable by search engines and load super-fast. Just like other websites, their links are sharable too. This, in other words, gives good user experience and result in SEO rank boost.
6. Offline capabilities:
Due to the support of service worker API, PWAs are accessible in offline or low internet connections.
7. Security:
PWAs are delivered over HTTPS connection and secure user-data over each interaction.
8. Push Notifications:
By the support of push notifications, PWAs can interact easily with the users and provide a really amazing user experience.
9. Bypass the app stores:
PWAs don’t need the App store or Google play store support. Their updated version can be directly loaded from the web server without the requirement of app store approval. On the other hand, native apps need days of approval if any new update required. There are possibilities of getting rejected or banned.
10. Zero installation:
During browsing, progressive web app gets its own icon on phones and tablets, just like a mobile application, but without the need to go through the tedious and slow App Store installation process.
Disadvantages of the progressive web app:
1. Less access to system features:
Currently, Progressive Web Apps have limited access to native system features than native apps. Also, all browsers are not supporting its full features but maybe in near future, it will be the new standard of development.
2. More Android – Less Apple’s iOS:
progressive web apps are currently, most supported by Android devices. Apple’s iOS is only partially supporting.
3. No review standard:
progressive web apps don’t need any kind of review system which is applicable for native apps from the app store. It may make the process faster but lack of promotional benefits from the app store.
Progressive web app checklist:
The checklist for the progressive web app is extensive. I have described its main few items here.
1. HTTPS
2. Web app manifest - manifest.json
3. Service worker
4. Responsive design
5. App icon
6. First load fast even on 3G
Conclusions:
There are huge possibilities offered for the progressive web app. Although there are lots of features and browser adaptability expected in near future. But, whatever already exists in the market is enough to show a strong mobile presence.
Visit the video blog: https://www.youtube.com/watch?v=NVXP-RzA0Eo
A PWA is a website with certain progressive features, most notably the ability to load offline or in areas with spotty connection, load quickly, display push notifications, and have other native app qualities. The benefits of a PWA is that they run on any browsers (since they're a normal website, if the browser doesn't support PWAs then the user gets a normal website experience), even desktop browsers. On mobile devices, the user will often get prompted to install the web app to the home screen, which happens almost instantaneously and uses barely any data since the website is already loaded. This allows for way more "downloads" than a native app, leading to higher engagement. For another brief overview of what a PWA, Google has some great articles about them.
Technically speaking, a PWA is a website that has two things: a web app manifest file and a service worker.
A manifest is a JSON file (usually called manifest.json) with some information about the progressive web app. It contains information similar to what you would include with a native app. It has the name, the short name for display on home screens, icons, orientation, etc. A web app manifest can be used on any site (even non-PWAs) to give the browser more information and allow the site to create a shortcut on the user's homescreen, but it's required for a PWA. You can read more about it over on the Google Developer's site.
A service worker is a JavaScript file that can be installed by the browser to do certain tasks. This file will be run in the background of the site and can do things like caching resources, intercepting network requests (to do stuff like return data from the cache), receiving push notifications, background synchronization, etc. When a user first visits your site this JS file gets installed and starts running. This is the file that allows for things like offline functionality. You can read more about service workers on the Google Developer's site as well.
Roughly speaking PWA is a web app that has native feeling and can be installed to the users' home screen and can start & work offline with an optional sync to server when Internet connection gets available.
To be considered a Progressive Web App, your app must be:
Progressive - Work for every user, regardless of browser choice,
because they are built with progressive enhancement as a core tenet.
Responsive - Fit any form factor, desktop, mobile, tablet, or whatever
is next.
Connectivity independent - Enhanced with service workers to work
offline or on low quality networks.
App-like - Use the app-shell model to provide app-style navigation and
interactions.
Fresh - Always up-to-date thanks to the service worker update process.
Safe - Served via HTTPS to prevent snooping and ensure content has not
been tampered with.
Discoverable - Are identifiable as “applications” thanks to W3C
manifests and service worker registration scope allowing search
engines to find them.
Re-engageable - Make re-engagement easy through features like push
notifications.
Installable - Allow users to “keep” apps they find most useful on
their home screen without the hassle of an app store.
Linkable - Easily share via URL and not require complex installation.
I think PWA is quite a broad term. I say broad because there are many ways of developing and distributing a PWA. In Layman's terms a Progressive Web App is a 'web site' that is effectively used/displayed like a native app. I believe an example of this would be something like phonegap? where phonegap built an app 'surrounding/scaffolding' and displayed a webpage with some custom CSS over the top. (Editorial Note: Phonegap is not related to progressive web apps. Phonegap creates actual, native applications. Wrapping a website in a native application is very different from progressive web apps.)
Most recently though I've been working on a lot of react only based website which I believe is the closest to PWA you can get at the moment (especially for IOS who only support minimal feature to encourage you to build native apps for their app store).
But yea it's basically an app like app that's not an app; rendering from a web page :thumbsup:
Progressive Web Apps (PWAs) are web apps that follow a set of guidelines
Starts fast, stays fast
Performance plays a significant role in the success of any online experience, because high performing sites engage and retain users better than poorly performing ones. Sites should focus on optimizing for user-centric performance metrics.
Works in any browser
Users can use any browser they choose to access your web app before it's installed.
Responsive to any screen size
Users can use your PWA on any screen size and all of the content is available at any viewport size.
Provides a custom offline page
When users are offline, keeping them in your PWA provides a more seamless experience than dropping back to the default browser offline page.
Is installable
Users who install or add apps to their device tend to engage with those apps more.
For more details see What makes a good Progressive Web App?

Device tells us we need Google Play Services to Use Maps on Android device

we've been working with a 3rd party Android device that uses API 17. We want to make a native Google API app so that we can map data for our customers. What happens is the app crashes and it says "Google Play Services required". Is there a workaround to this? can we somehow embed or package a file that is good enough to use Maps? We've spoken with the hardware company and they made a decision to not allow google play services. We are partnering with them to release the device with a couple of apps we offer with the device. Any help is appreciated
Google Play services enables Maps to run on your Android devices, as per Google statement:
With Google Play services, your app can take advantage of the latest,
Google-powered features such as Maps, Google+, and more, with
automatic platform updates distributed as an APK through the Google
Play store. This makes it faster for your users to receive updates and
easier for you to integrate the newest that Google has to offer.
That means you need Google Play services to make Google Maps work.
Download it here.

itunes connect metadata rejected video third party, how to resolve?

I uploaded my app to itunes connect and I waited a few days.. and then the app that I uploaded was denied one time. I send them one video explaining the app, but anyway they rejected the app.
This is the first message:
We began the review of your app but are still not able to continue because we need access to a video that demonstrates your app in use when launched on the physical device and integrating with third party product. Please showcase all app features and functionality within the video content provided. The simulation video provided will not suffice.
This is the second message:
The simulation video provided will not suffice. We need access to a video that demonstrates your app in use when launched on the physical device, and integrating with the third party product. Please showcase all app features and functionality within the video content provided.
What do I need to do? Use a screen capture software and film my app in use in the iPhone? Upload to youtube and share the link in the review notes of the app? A simple demonstration? or a expanded demonstration?

PIN authentication on iOS app and then listing all ios apps

I want to list all my published iOS apps list on my main ios app .
My main iOS app will perform like this: First screen will ask to enter PIN (an authorization code, user will have this code from my other web url ) after validation, next screen will show all published app (published from my developer a/c) of iTunes store. apps will be a free type category, if user click on any specific app, the itunes app should be launch to download that app on device.
Could some one please suggest me , is there any violation of Apple's rule to show my apps in this way authentication to my customers? Will apple reject my app?
Although i was trying to understand a search API of iTunes
http://www.apple.com/itunes/affiliates/resources/documentation/itunes-store-web-service-search-api.html
Thanks a lot,