I've made my app running on the Google Glass, but it's a little slow in real time. Is there a way to connect my Android phone with the Glass for data communication, so that the phone can take care of the calculation, and the Glass only show the result? The Glass can tether with Android phone by bluetooth, so it should be able to transmit data via it?
Don't know if it's possible to run my app on cloud server and send the result back to my Glass, but guessing that would be slow as well.
Any suggestion is more than welcome! thanks.
Yes, you can connect your Android phone with Glass for data communication, to receive internet content for example. This can be accomplished using Glass to WiFi (but you need the phone to set this up the first time), or Glass to phone to Bluetooth if your phone supports bluetooth tethering, which is often a carrier option.
If you are a Glass explorer this should have been explained when you picked up your Glass, but you can contact the Glass Guides for more information, if you are a Glass Explorer you will have this contact information. I have found them to be extremely helpful and fun to work with on usability questions. It doesn't hurt that if you visit them physically they ply you with treats and drinks.
If you are asking if you can open a socket directly between phone and Glass, that is not supported functionality, but you can request it. It might be possible when the GDK is made public, but there is no timeline for that.
If you wanted to do calculations on a phone and pass them to glass they would have to go through the cloud, as described here. Check out the section titled "How developers interact with Glass" and the accompanying graphic. I find it to be fast (sub one second with good connectivity), but that is subjective, your speed needs are not well defined in your question. A consideration is that every round trip of data will count against your API console daily limit, which is 1000 for most everyone. There is also a 10 request/second limitation.
Last note - there are unsupported ways of talking directly between Glass and a phone for a device you have direct access to, but this is not supported, and could not be used by other Glass users very easily. The techniques to accomplish this are alluded to in the Google I/O 2013 session: Voiding Your Warranty: Hacking Glass.
This forum isn't an appropriate one to discuss this, if you were to contact me directly somehow I could give you some pointers in the right direction, but I don't advise this route at all.
Related
Can we use the newly launched Microsoft cognitive services for crowd analysis and audience measurement? I need to create an application which can detect faces in live video and provide the characteristics like gender, age and mood
Face API is designed for image processing, if you want to use it on camera stream, you need to handle the input yourself. Something like just picking several frames and send the image to Face API cloud service. If possible, you can have this [1] as reference (though the code might be a little bit old).
[1] https://github.com/Microsoft/Cognitive-Samples-VideoFrameAnalysis
I have an idea for a mobile service based project. I have read some stuff online, including the following tutorial: SMS Tutorial and find it to be pretty helpful but I have some basic questions so please bear with me.
I run a small (as in me and a friend) company and want to setup a situation where people can text a number and receive information back, or setup on my website that they receive text messages letting them know its time to do something, or "tech support" can text them if they wish, etc.
So from what I've gathered, I can use Kannel as my "SMS gateway" interacting with a GSM Modem that I can purchase. For this modem I can buy a texting plan SIM. I can then setup Kannel to use my GSM modem as a virtual smsc. So, users can text that SIMs phone number, which will go to the modem and be interpreted by Kannel. My application will only have to interact with Kannel. And in the future, if I decide I need more texting throuput and upgrade to a real SMSC my application does not need to change.
Is there anything I'm missing/misunderstanding?
Thanks!
Using Kannel as a SMS gateway is a good option for a small company. It does come with a lot of headaches as you have to build, configure, maintain, etc.. all of the services you need, This is what everyone is referring to as "A lot of work".
What you are looking to do is use the GSM modem as a Long Code (verses short Code) for text messaging.
I think this is an expectable solution for something small and where service, latency and availability might not be as important if it's for a local region. But if this is something that needs to be reliable I would think about getting a short code (or sharing a short code) or just a SMS Messaging service with No Long/Short Code (See Twilio Below).
Also if you're trying to rollout your own service there are some things to consider with the SMSC's. If your Kannel/GSM Modem doesn't support the Carrier, you would have to reach out to that Carrier and connect to thier SMSC. This is a hefty price to connect to a Carrier. This is way Aggregators are appealing as they Have all the Carrier connections and pay those fees.
As you transitioning from Kannel to a Gateway Service Provider, that's another headache as you would need to start from scratch and use whatever the service provider API is and replace the Kannel/GSM altogether. Your workflow might be the same but how you send and receive messages with differ greatly. Most (if not all) Aggregators will offer there own version of a SDK/API/Service that you would need to comply with to use their service.
If it's in the US there are some other options you might consider:
Twilio, this is the simplest solution I've seem for smaller companies looking for SMS functionality. Now they are currently offering SMS Short Codes by trial but if you need a short code I would go with a true messaging aggregator.
Zeep Mobile Offers a free SMS service with a Short Code, but they do send Ads with all your SMS Messages. This is a great way to subsidize costs if the Ads don't bother you. Not sure if you can pick the types of ads you want but it's another option for a service.
Clickatell offers a service where you can Share a Short Code and use Keywords to filter your SMS traffic to your account. This is another way to cut some costs if you're funds and traffic (how much SMS you send and receive) are limited
OpenMarket offers a full service SMS/MMS global platform, this is who you want if you doing Mass amounts of trafic and/or need to reach globally.
Note: These are just a few services as there are many, many more
There are also some caveats with having a Short Code as you will need to register a new Short Code if the country you are services needs it's own Short Code. Example: you can use your US Short Code to service Canada, You would also need a Canadian Short Code as well. This can get costly if your only doing small amounts of traffic.
I think you have got basic considerations. John is right, and using a sms gateway is better idea, you will get better reliability and thoughput. And you could get slow prices.
I want to be able to track a person through their mobile phone and
display those whereabouts on a website. I read some stuff here about Safari and iPhone.
What I need is a starting point in the sense of what is possible, and
if it is only possible for certain phones. I can ask a lot of specific questions as I've read bits and pieces everywhere, but what I need is a general layout of what needs to be done and, if possible some of the steps to accomplish it.
Thanks.
Well, if we assume you are starting from scratch, here is a high level list of things to figure out:
familiarise yourself with geolocation coordinates and the gps system. If you need to make sense of the raw location data, there is some math involved.
pick a location-aware mobile platform. Some phones will implement jsr-179, which is a JavaME API. In addition, you can get location data using python or C++ on Symbian phones. I suspect Android and iPhone both have their own location API.
figure out application deployment for the platform you picked. How does the mobile application get on the device? A phone manufacturer or network operator application store, a third party store like www.getjar.com, pre-installed on the phone via a partnership with the manufacturer or the network operator...plenty of options.
come up with a sensible way of packaging mobile location data and send it over the network to a remote server.
make a website to display the location data stored on the server.
I've just discovered J2ME and I love the possibilities that it presents. I'm currently working on a simple application and I'd like to maybe release it as an open-source project sometime in the future.
As part of my research into J2ME and mobile devices, I looked into applet signing. It seems that people who want to create applets for free are caught between and rock and an awful shite-place. Applet signing is extremely expensive and extremely convoluted - and the expense can't be justified when coding for free.
There are a huge number of J2ME compatible devices out there - I think it would be a shame to have to ignore them, and just wait patiently for the next wave (e.g. Android).
I was wondering if other people have any ideas about ways to approach this problem?
UPDATE: I found this blog article which summarises the problem for those interested... http://javablog.co.uk/2007/08/09/how-midlet-signing-is-killing-j2me/
I thought about setting up a non-profit umbrella organisation for open-source J2ME developers who want a VeriSign certificate (as a certificate can sign code an unlimited amount of times). I would aim to raise the $500 and then enable group members to share the purchased certificate. Had a quick chat to a VeriSign rep and they thought the idea could work (as long as the organisation was registered as a legal entity).
However, since handset manufacturers now seem to be moving to support only UTI root certificates (which you can only get through the 'Java verified' programme) - this might not be as useful as I thought it could be... if anyone has any ideas would be great to hear them.
I am afraid that you are fighting a battle that you can't win. Using the restricted APIs is getting harder and harder and this is not accidental. As you've read in the blog entry you've mentioned the biggest problem is the network operators. Even if you buy a certificate from Verisign or Thawte (which is by the way cheaper), your application won't run in network operators branded phones, since these have their own CA rules.
At first it was possible for a developer to install his/her own certificate, but even this is now not possible. This strict rule is mandated by the phone manufacturers (Nokia for example) and applies to all phones (even no branded ones). I believe that this too is not accidental and is mainly because of pressure put to device manufacturers by the network operators.
Finally, although MIDP 3.0 has been announced for years, nothing has really come out of it. It seems that even Sun believe that J2ME is only for games.
All of these have been extensively discussed in J2ME forums for a long time. The general consensus is that the network operators do not want to have every phone available in the market operate as a smart phone and be able to run a third-party application. Then it will be very easy for everyone to use a cheaper, web-based alternative instead of SMS messaging for a example. This may sound as a conspiracy theory, if you are new in the J2ME world, but have in mind that network operators sell phones with their own firmware that lock even basic functionalities (e.g. transferring photos via Bluetooth or using MP3s as ringtones) to force the owner to use paid services!
I don't know if this is going to change now that smart phones (iPhone, Android, Windows Mobile) are gaining momentum. Have in mind that restrictions apply also for these platforms (notably Symbian, which is also very unfriendly for open source).
You can create a signing certificate
that you self-sign. Your users have
to be willing to trust you.
You can instruct your users how to
create a cert and self-sign with it.
Then the users have to be able to
trust themselves.
There are more or less open CAs; you
have to be willing to trust them and
convince your users to trust them.
The Java Tutorial has a section on signed applets that will lead you through the steps.
I'm a J2ME application developer and i totally agree your post. The costs for signing a MIDlet are simply unaffordable for open source initiatives and unless your're developing simple games, you'll soon or later end up in using restricted APIs to access sockets or Location API just to name two of them. This is very frustrating and if you consider that the permission policies are not always threated the same on various devices, the thing get worst: on some mobile phone you can tell the OS to trust the entyre MIDlet and never bother you at all, other continue to ask you permission every time you call for a restricted method. It's tragic!
I rellay appreciate your proposal and i think it would be a great achievement for JavaME developers.
Speaking entirely in technology-free terms, what is the best way to make a mobile friendly site? That is, I want to make a site that will work on a regular computer but also have mobile versions of the pages. Should I rewrite each page? The pages will probably have different functionality, so should I rewrite the backend code? Should it be an effectively different site with the same database?
On my site, I detect user agent, and for known mobile browsers I serve a different stylesheet, with some larger/less necessary items left off some pages. The backend doesn't really change.
I added a mobile presentation layer to an operational site about a year ago. Based on the architecture of the site (hopefully this isn't too technology dependent for you) I added a new set of JSPs to accommodate mobile browsers (sidenote: see http://wurfl.sourceforge.net/ for a great way to build mobile pages independent of browser type). Additionally some of the back-end functionality was changed due to the limited functionality of most mobile browsers. So, in short, the integration wasn't as painful as one would expect.
Good luck!
This is a pretty broad question, but here goes:
If the site is primarily about the content, meaning it's not so much a service you use as it's a publication you read, then I'd try to avoid publishing two sites wherever possible. Concentrate on simple presentation using mature technologies that mobile browsers can handle fairly well.
If it's essentially a software application delivered via the network, then things get trickier, because you're going to want to consider the UI of the mobile device, and how it differs from the desktop.
This should go without saying, but either way, if you have many mobile users, you should keep that in mind when you author content for the site. Formats, length, voice, etc.
In addition to the WURFL / WALL capabilities system that todd mentioned, there are Java Server Faces libraries available that use alternate WML renderkits for mobile phones.
One way I have done it in the past was to make sure my data was abstracted well in the data tier and then use separate middle tier models to pull what was appropriate. In my case the application was a weather application and the display methods of the target devices were really limited so we opted to only show the user the essentials on the mobile devices while the website was full featured. That was probably 10 years ago when WAP was big. But these days with devices getting bigger screens, better bandwidth, you may want to consume and display the exact same data with a different view model.
I never really know what type of application will need to consume the data in the future. We do a lot of apps across platforms but the domain model rarely changes. So I end up using the same middle tier objects where I can and pulling that data in different clients. A good example of this is a recent project where we had a rich internet application (widget), a full website, and a web service consuming the same data. Data abstraction in the middle-tier really shines in this environment.
On a very high level of abstraction, there are two main caveats with mobile devices: (1) their screen is small, (2) their network connection is intermittent. This basically means that your need to present the content so that it looks fine even on a small (variable size) screen, and preferably make it cacheable too so that your users can browse the content while offline. Then there's also the problem of low bandwidth and high latency, but those are slightly less important nowadays.
This is a very thorough overview of how to make a site mobile, though i hope its fair to say that there will always be different requirements for anyone seeking to go mobile. If you have a Blog, then you could just as easily make it mobile friendly using Mippin Mobilizer; its free, provides branding customisation tools, and with a big audience already browsing a wide mix of mobilized content, there's opportunities to generate advertising revenue around your blog.
This is because the Mippin Mobilized blog then becomes part of a much wider community of content, people, news, blogs, listings, all connecting around content, and much more at the mobile site:
http://mippin.com (on a mobile browser.)
Take a look at the Mobilizing tool because it shows off what the site can do in a second:
www.mippin.com/mobilizer
Only if you have a blog of course...