I have an application on Samsung Smart TV. I'm fetching data from web service and display this data in my application.
I'm fetching the data periodically and updating the application accordingly.
I want to run this operation as a background process, so it'll download the data and if there is an update, I warn the user when s/he watching TV.
The other thing I want is to start application on TV launch, is it possible?
Only 'ticker' type application can run in background. It is not supported in Europe and will not pass certification for Samsung Apps store.
Samsung Smart TV suppots push-notifications (samsungdforum.com/Guide/art00080/index.html).
It will allow you to show popup-message on screen with ability to launch your application.
You cannot auto-start application on TV launch.
The only way is to use custom firmware like SamyGo (http://www.samygo.tv/)
About the "background process"... as far as we assume that JavaScript's setTimeout or setInterval can be used to execute application's "internal" background process, there is no problem - Just DO it! :)
But if you were thinking about system's background process - for ex. crontab of device - it's impossible.
for your second doubt
Auto launch of the application is supported in ticker applications only and there is property in config file of the ticker widget :
"<ticker itemtype="boolean">y</ticker>"
if u mark it as y(as above) than you can set up auto launch of the app from
Menu->smart Hub->Apps settings->auto ticker. in 2014 Samsung Smart TV models.
Since Tv has limited memory I wont recommend background process like setInterval or setTimout. You may have refresh button for the same.
And They must have some js api for controlling internal method of tv application (not sure). Anyway if you really want to use interval/timeout dont forget to clear it.
As it shown here, WebSocket is supported by Samsung Smart TV. Your server application can trigger TV application when an update is appear. It is more efficient way than polling server with ajax for your case.
(Edit) I wrote a sample application to demonstrate:
https://github.com/aksakalli/socket.io-hello-world
(Edit 2) I see that your problem is about platform limits. My answer is just about approaches that can be applied then I have very limited experience on Samsung Smart TV.
Related
We all use Zoom or Webex to attend the meetings, then there is a popup that allows you to open the desktop app or you can continue on the web app. I want to implement a similar kind of user experience in my web application. But unable to understand how did they(zoom and Webex) did it.
I am not looking for a foolproof solution I just need to know the best approach to achieve it.
Update:
I am not doing it exactly like Zoom or Webex does. I have a button in my application so I am doing it onClick event.
In order to do this, you must register a protocol on your OS (ie. you can use protocol lib to register a specific one in an Electron app), this would allow your app to be called with simple URIs like myappprotocol://myappaction?myappparams
They make you install a client, that has caused many controversies since this is a gate for eventual security breaches
https://medium.com/bugbountywriteup/zoom-zero-day-4-million-webcams-maybe-an-rce-just-get-them-to-visit-your-website-ac75c83f4ef5
I am creating a React JS web app which will eventually be converted to a PWA so that the users can install it on their mobile devices. Now the client ask to find out a way to push these PWA apps to apple store and google store. So my query is whether we have tools for converting the Progessive Web Apps as apk or ipa files so that we can put them to apple store or play store.
I googled a bit and is right now confused because some say it is possible, some say not possible in Apple store. I also saw some tools like PWABuilder, but I am not sure which one is the right one to use and whether we can publish a PWA app to the app store and play store.
Any help on this will be very grateful.
Thanks
While it is possible in both cases, publishing a PWA on the Apple Store is an incredible difficult journey, because Apple engineers try to build obstacles all the way long. This is by decision as Apple is making profits from its app store and PWAs would indeed subtract some of these gains. This is also the reason why Safari, as browser, is incredibly behind the other competitors in supporting PWAs APIs (PUSH API for example, as they promote their Apple Push Notification Service (APNs)).
Long story short, I would concentrate on Google Play Store, where you can publish a PWA after having wrapped it into a Trusted Web Activity (TWA), allowing Chrome (v72 or later) to run a website in fullscreen mode without a browser toolbar within an APK (Android Package). You can find further details in this tutorial to publish a PWA on the play store.
You could use Capacitor to create a native App.
It is newer than Cordova.
Here you can see the Stackoverflow TagTrend: Capacitor vs Cordova
... or wait some month. Sooner or later you will get PWAs into the Apple Store. I don't think they are able to stop this process.
I published my pwa to google play store and apple app store. I used App-bound Domains for ios and Twa for android. I think at this time to simple to publish some pwa to appstore.
I've just started learning ionic framework. It uses web browser capabilities for building apps.
These capabilities namely HTML, javascript and CSS are client side stuff. Which on browsers can be seen with view source.
My questions is how will be the visibility of the source? Will the end user be able to see the source of the app?
If yes, is it normal for any app? Shall one be worried about the security of the source?
The visibility of the source in chrome://inspect#device , is pretty much the whole application. And no, end user cannot see the source of your application once you set and push the project to production mode.
Well, since you are developing a hybrid application, there are of course, pros and cons for each. Security might not be as strong as native apps, but development time is greatly reduced to push the app to different platforms.
If you would to do something would requires high security and non-visibility of your source , then native is the way to go. As for hybrid apps,if you need somewhere to store your data securely, you will need plugins to communicate with native platform's secure storage which might pose a security risk. But then again, even native applications can be de-compiled. The way developers tries to make it harder is via obfuscation methods.
Once u set your application to production mode, you will not be able to inspect your application anymore.
To show your web-app on chrome://inspect/#devices :
1) Make sure your web-app is running and your phone is plugged into your computer via usb with USB debugging on and your PC is trusted by the phone.
2) Under device manager, you should not have missing phone drivers. (it would look something like this)
3) ADB should not be running co-currently. And you should be able to see something like this on ur inspect page:
4) Click on inspect button and you're done! (:
You have a signed apk, when you install it on a device and inspect the device on google chrome the inspect option will not be available. Theres an easy way to do that decompile the signed apk using apktools you will get the AndroidManifest.xml file. simply add android:debuggable="true" to the tag and recompile it resign it and you will be able to inspect it. If you check the main.js file in the inspect section the source code is visible.
Hence you can use Jscrambler to prevent this (Its a paid service i too am new to it)
I'm writing a JavaScript based Android application (using PhoneGap) to track patients' compliance with their medical regimen. This requires the app to run in the background and remind the patients at specified times to take their medication. Since PhoneGap based apps do not run in the background, I was wondering if I could remotely start the app on the patients' phones (assuming I have their permission, of course) using NodeJS (which I'm using for this app anyway - to gather the compliance data).
Alternately, I was wondering whether I could trigger a dialog box on the mobile phone remotely using NodeJS.
I'm sorry if these questions sound silly... I'm new to this stuff.
Thanks in advance.
I want to build and application through which an user can input some settings and the application will start a background service to perform some tasks based on those settings.
I want to run the application and the background service only in the Simulator (I know that it requires "certified" mode for running a background service, but I am not thinking right now for posting the app on Firefox Marketplace).
Can someone provide me with some links or tutorials on how to build and run a background service on FIrefox OS platform? Can anyone also explain how to communicate between the background service and the application? (I have search the MDN and on google, but no luck).
Also, is there some way for application (regular app or background service) to listen for notifications from a server?(I am looking for a method in which the application does not pool, but is notified by the server).
Thanks,
Tamash
Can someone provide me with some links or tutorials on how to build
and run a background service on FIrefox OS platform?
This is planned of a future version of Firefox OS. See "Background services" at https://wiki.mozilla.org/Webapi
Also, is there some way for application (regular app or background
service) to listen for notifications from a server?(I am looking for a
method in which the application does not pool, but is notified by the
server).
This doesn't seem to be implemented yet. See https://wiki.mozilla.org/Webapi and https://wiki.mozilla.org/WebAPI/SimplePush
The wiki page above is out of date - though it hints at what's coming.
Currently the RequestSync API has landed - it allows scheduled wake-ups for synchronization purposes. This is not an always-on background service. It's planned to ship in the 2.2 release of Firefox OS.
RequestSync is not yet documented on MDN but the implementation bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1018320
RequestSync is a partial solution until we have full background synchronization through Service Workers.
Service Workers are in the implementation stage now: https://bugzilla.mozilla.org/show_bug.cgi?id=903441
Draft documentation on MDN is here:
https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorker_API