Lately I have been wondering what is involved in preventing the Browser/App background video playback feature that is part of iOS and Android.
Recently, Youtube also moved the playback functionality (That I understand is part of the OS) behind a paywall. A few years ago you could play videos in the background without trouble. Then the feature's availability started being exploited and eventually moved behind Youtube's subscription service.
I'm curios if this is a decision by the mobile developers to prevent battery drain, or are mobile OS developers allowing app developers to exploit the background playback feature that, from my understanding, is/was part of the mobile device's OS.
I'm asking on stackoverflow because it seems like Developers would understand what is happening here. Does anyone know, or could point me to information that describes the reasoning behind this move?
Related
Can anyone tell me how apple handle submissions for bluetooth BLE enabled app. Actually, i have created a bluetooth iphone app which connects to third party device. And, I am not sure how apple is testing apps which connects to third party devices.
Object Lab has recently launched their first iOS app using iBeacon. It took them 3 attempts to get it approved. I would recommend you to create a video which demonstrates how your app works and send it to them.
Generally they ask for hardware as well but mostly it's not feasible for us to provide them with one. Object Lab had to send them instructions to setup hardware at their end and to test the app. THEY WILL NOT APPROVE UNLESS THEY KNOW ITS WORKING. So I would recommend to send a video and step by step instruction of how to setup hardware at their end to test it out.
My experience has been that a video demonstrating the use of the app while connected to your third party device is enough. Sending the device to them is not necessary (at least for all cases). I know there is another thread on stackoverflow.com concerning this very thing, but it's been months since I had found it and I can't find it now. Anyways, it has worked for me as well as acquaintances of mine who have an app on the store.
I'd like the app to advertise a service even when the app enters the background. With Core Bluetooth, this is possible by setting bluetooth-peripheral for UIBackgroundModes.
Does anyone know if the same can be achieved with MCNearbyServiceAdvertiser? Thanks.
When I was at WWDC this year I went to a Developer Lab for Multipeer Connectivity and was told by an Apple engineer that no, service advertisers and browsers will not work in the background.
That said, I've been successfully communicating with connected peers with an app running in the background using a background task, but I have not been able to advertise or browse.
As far as I understand, Microsoft wants to allow "having both desktop and modern ui GUIs" only available for web browsers (am I mistaken here ?).
Does that mean common apps will be developped twice ? With e.g Skype being available both as pure desktop app and pure modern ui app ? And if a user installs both, these both instances will share no data ?
I can't imagine them doing a shift towards gesture friendly uis/hybrid ui, and leaving full blown desktop apps (not toy/phone-like/game apps, that can live in one space only) with no integration/entry points inside modern ui. Or maybe they want to participate in that "kill full-blown desktop apps" movement ?
So is there a model for a desktop app developped in whatever GUI toolkit, that wants to have some minimal integration with a small HTML/CSS/JS frontend in modern ui, like for e.g providing a dashboard of favorite or recently accessed files, contacts, etc ?
Your first statement of "only in a browser" is not correct. Desktop applications don't change their current design paradigms. You can have browser-based apps on the desktop, of course. But full clients are still supported and still viable as a real solution to problems.
Your takeaway from that comment should be that desktop applications are not deprecated as people assert. The reality is, desktop applications are still the only solutions to many problems.
Your second question of shared data is not correct. Skype shares lots of data with its app companion. Not because of shared local storage, however; it is because of the services that it shares. My account and contacts are on the server. So, they share a lot.
Your takeaway from that comment should be that Windows 8 apps should not highly leverage local storage but should be built as service-oriented clients. To that end, your desktop applications should have already started to leverage this architecture, too.
Your third question (which is very cryptic) seems to be asking if a desktop application and a companion Windows 8 app can share or integrate with each other. The answer is yes. Not only can they share the same service, but file associates, custom protocols, and some of the non-Store manifest capabilities allow for this explicitly. Line of business applications should have a companion app, if you ask me. The integration points are many - though not every. But there is no other way to leverage the new capabilities of Windows 8 without introducing a companion app - even if that app does very little.
Your takeaway from that comment should be that Windows desktop applications and companion Windows apps are the preferred and anticipated development approach.
Best of luck, thanks for the question.
I want to develop some small apps for personal use. I don't want to market them, nor I want anyone other but me to have them. As a developer, I want to be able to put some minor utility app I'd like to have on my own smartphone (an iPhone, of course).
As I'm not going to develop anything commercial in the near future, I'm not going to subscribe the developer program. Is it possible to develop personal apps without subscribing to Apple's program? Would jailbreak help? Am I going to miss any possibility in the development (ability to subscribe to servers, message, use the maps...)
Thanks
there's a number of threads of this.. they all use ldid and are normally jailbroken
How can I deploy an iPhone application from Xcode to a real iPhone device?
Attempting to deploy my app on my jailbroken iphone, but the app closes immediately!
at first i thought with Titanium, i can develop for Mobile and Desktop over AIR on Desktop only, but a quick look at the AIR Site, i guess i am wrong.
Benefit from a consistent, flexible,
and visual development environment for
applications on multiple platforms and
devices such as smartphones,
smartbooks, tablets, netbooks, and
PCs.
so my question is are there any major differences of titanium over air that i shld be aware of?
if no, i guess now air maybe better documented and has the backing of a more recognized company? after working with titanium desktop for a while i felt abit helpless and the docs are not really helping much
There are a lot of subtle differences, of course, and there are advantages and disadvantages to working in either, but the largest difference is that Titanium can produce apps for the iPhone/iPad, and AIR can't (well, at least not conveniently).
AIR can produce iPhone apps that you can deploy using the ad-hoc provisioning, but you can't distribute via the app store.
I've got desktop apps on both and am making a mobile app right now. Titanium desktop will cut your dev time to 1/3 of the time you'll take jumping through AIRs various sandboxes and security measures. Best yet, the code I wrote for my Ti desktop app is all javascript with about 3 Ti API calls and can be taken anywhere. The AIR app is all mangled by the wild structure you have to use with AIR apps and 1 million api calls.
The downside to Ti desktop is the API isn't as fully featured, and the Ti team pushes 4 times as many updates for the mobile API as the desktop API. Also, you won't be able to port your app from desktop to mobile easily as they are two different structures and APIs.
That said, developing for iPhone and Android on Ti is the same exact process and that won't happen on AIR.
Lots to weigh, but for my money it's Ti over AIR.
Hope this helps.