specifically when using cast_api.addReceiverListener("YouTube"..... can I launch any activty besides youtube?
I don't want to write my own receiver application, what are the builtin receiver applications I can activate?
Is there a built in application to launch an arbitrary URL?
You cannot launch any application that you want. Currently, your device needs to be whitelisted for an application and outside of your own app that you may have registered through the whitelisting process, there are very few apps that are "openly" available to you, such as YouTube.
At the moment, if you want to do anything "interesting", even playing back a simple media file, you need to write your own receiver.
Finally, there is no application to launch an arbitrary URL; you need to write your own receiver and app to achieve that (unless you mirror your Chromecast tab).
Related
I have two unique sandboxed Cocoa applications. I wish for one of these to be able to provide some data on-demand to the first application, but without first requiring the launch the second application. For this, I'm thinking of creating an XPC service in the second application and then using it from the first.
Is this possible? I have the privilege of enabling "App Groups" if that would enable this functionality, as all the examples and code I've seen so far require the service to be bundled inside of the calling application or require the second application to be running. I don't want the launch the second application as the data can simply be obtained by querying the database and does not require interrupting the user's workflow.
Is this possible to do?
Would it be better to instead create a background Login item in the second application and use the Groups Container to communicate using files? That's highly inefficient and I'd personally prefer to be able to communicate between the two apps.
We have a number of TVs where we want to display dynamic content. This is very similar to the built in Chromecast application that displays photos and art from Google, the major difference is that we have a mixture of photos and videos, and want to display for instance a whole video clip, then a few photos for 30 sec. each, then another video, then more photos, and finally when all is done, cycle through the whole thing again. We want to do the setup once for each Chromecast/TV, then let it run for days or even weeks.
One option could be a web server displaying the whole sequence repetitively on a specific web page url, and then have the Chromecast display its assigned web page. I looked at the development docs. and I suspect that I will need to develop a Chrome Sender application and use the standard receiver application on the Chromecast. It is not clear for me if the sender (Chrome) needs to run all the time, or once the setup is done, the Chromecast knows which url to display and can then be left alone for days.
We hope to replace dedicated servers and software that connect to the various TVs, and the Chromecast offering customization could be a very inexpensive solution.
Maybe this does not make sense, let me know!
The sender can be a chrome sender or a native app on an Android or iOS device; as for the receiver, you would need to write a custom receiver; that receiver, which is basically an HTML5 page, can receive the whole schedule (urls, etc) at the very beginning, or it can fetch the schedule dynamically from a certain server, etc. Once the receiver starts, your sender doesn't need to stay connected but if for whatever reason your chromecast is rebooted, or loses connectivity, etc, your sender would need to start your application on the chromecast again; there is no magical way for chromecast to start your app automatically.
I am wondering if there is a way for a Firefox OS app to broadcast an event to all other apps and for the interested apps to hook on that event and trigger a corresponding action.
An example of use case I have in mind: the Camera app broadcasts the event "picture taken" and another app hooks on this event and take some action on the new picture that has been taken (for example, uploads it to a server).
There's not currently a web API in Firefox OS to broadcast events to all open and/or interested apps.
For your particular use-case of apps being notified when a new photo is taken by Camera, the best approach is probably to open DeviceStorage for "pictures" and listen to "change" events.
Documentation for this is at:
https://developer.mozilla.org/en-US/docs/Web/API/DeviceStorage
Alternatives exist but are more restricted functionally, and available in fewer releases and contexts:
The system can broadcast messages, but only certified apps can listen. https://developer.mozilla.org/en-US/docs/Web/API/Navigator.mozSetMessageHandler
The InterAppCommunication API allows web applications to message one or more other apps, but in a more tightly coupled way than a general broadcast. However this API is not yet standardized, and is only available to certified apps. https://bugzilla.mozilla.org/show_bug.cgi?id=876397
Access to system preferences is coming soon for non-certified apps, and maybe could be used to do this, but that's a hacky way of accomplishing messaging and data sharing. https://developer.mozilla.org/en-US/docs/Web/API/SettingsManager
Note: For every example here, your app would have to be running for it to work. There's no mechanism for waking an app up when a specific action or event occurs. Web Activities is the closest API for event-specific app loading. Timers API is for non-specific app loading.
From this article[1]:
App authors can build an app that will handle one or more activities. That means that the app will be callable by another app to perform some specific actions defined by the activity. For example, let's pretend we want to build a photo manager. It could be used by another application to pick a photo. As an activity handler our app will become part of the other application's workflow.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Activities
I am working on a product for Windows 8 that needs to perform some low-level tasks, display some UI, and communicate with an external server. I definitely need a Windows service to accomplish the low-level tasks. At the same time, I would like to use the cool features of Windows App Store apps, like push notifications, live tiles etc... for the UI. In this design, both my service and my app would communicate with my external server.
The flow would be something like: my Windows service sends some information to my server, which then sends a push notification to my App Store app.
I understand that deployment is not pretty in this scenario, but let's put that aside for now. My problem: How does the server know that the service and the app are on the same machine, and consequently linked together? i.e. When my Windows service sends information to the server, how does the server know where to send the push notification? I need is some sort of shared, unique, identifying information.
I have seen lots of discussion (usually frustrated in nature) about the lack of inter-process communication between App Store apps and desktop apps. In my case, I have two options:
Generate the exact same unique identifier in the service and in the app. This seems unlikely because apps don't seem to be able to access very much system-specific information. I'd love to be shown that I am wrong about this.
Generate a unique identifier in the server OR in the app and communicate it to the other component. Potential ways to do this:
Create the identifier in the app, save it to a file, and then access the file from the service.
Some sort of local socket solution (I've read this doesn't work, but have not tried)
Of course, option 2 seems likely to violate the Windows 8 app Certification Requirements, notably:
Windows Store apps must not communicate with local desktop
applications or services via local mechanisms, including via files and
registry keys.
Any advice would be most appreciated.
I'm not a lawyer, but if it says "via local mechanisms" then you could still possibly communicate via a cloud service as long as having both apps installed isn't necessary to have some features in the app or if you don't mean to publish the app in the store.
You could save some sort of a token in the documents folder or if your desktop app can run with appropriate permissions - it could access the local data folder of the Windows Store app to synchronize the token for use in communication with the web service.
Perhaps the user could just be asked to copy and paste a token between the two apps?
I'm trying to write the most basic application for windows phone 7 and want to be able to send files (specifically XML in case that changes anything) to my app. Currently I have a WCF service setup so I can send push notifications through it. The problem is that there is a limit on the amount of raw data I can send via a push notification.
My solution to this is to send the initial push notification (either tile or raw) to alert my application that I want to send a file to it and then make the app somehow communicate with a server (everything is on my personal computer btw - I'm just trying to figure out how things work) - from which the app will recieve/download the files.
What is the easiest way to accomplish this? Note that I'm not concerned with security or anything like that.
Clarification - the question is essentialy: how do I transfer files from/to a server to/from the phone? Assume everything else was handled - the app is up and running and the user has given or will give permissions to every possible thing he may give his permission to.
Unfortunately, the total size of a push notification (including HTTP headers) is 1kb. This means that it can't be used to send large amounts of data.
Instead of sending the whole file, send a notification (raw or toast—as appropriate) which should be treated by the application as a trigger to go and retrieve the new file/data/whatever from the server. It may also be worth checking for new messages when your app starts. However, if when you start the app it will notify the server that it is ready to receive raw notifications and such messages will be sent indicating new content is available, it may be unnecessary to add this extra check.
To transfer files to/from the phone you will need to use either HttpWebRequest or WebClient as this is the only way to use HTTP on the device and HTTP is the only protocol currently available to transfer data.
While WebClient may appear to be easier to use than HttpWebRequest it is less flexible and will automatically perform it's callback on the UI thread and if you're downloading files in the background you almost certainly don't want this.
There is no way to transfer files to/from a conencted PC and have them exclusively available to your app.
First of all: you won't be able to do this approach automatically - the user will have to open your app to do that because WP7 SDK doesn't allow your app to run on background/start automatically once a push notification is received.
The only way to communicate with your server, at this point in time, is web services. If I were you, I would check for new information available once the app is started, if there is new info, I would call one or more web services which would return me all the information that I need.
If you want, you can use a timer to check for information periodically.
As I said, it will only work while your app is running (check the app lifecycle if you don't know it yet), WP7 doesn't allow apps to run in background, that is a serious limitation IMHO.
Good Luck,
Oscar
Maybe a little bit off topic but when I was thinking about file sharing in my WP7 app, I found two approaches:
Integrate an app with Dropbox
Use advanced explorer for WP7
You can use the WebClient class and the DownloadStringAsync method in order to download data from a web service .
A good example of this is Scott Guthrie's Twitter app from MIX10 .
George