I am looking to have a Symbian Series 40 application to take a photo using the onboard camera every 5 minutes and then upload the image to a server via GPRS.
Is this possible? I need to know whether this is possible before going deeper into it. Would S60 be better?
Here's a slightly corrected version of the code linked by Mihir (it had an obvious bug and another bug which is probably an interoperability issue) which works on my Nokia 3110 classic: Java ME Image Capture Example
Related
I am trying to find a Chromecast solution, whether I write it myself in macOS/Swift, or there is something already in the works. I came across the Chromecast SDK, but I see it only support Android and iOS. Has anyone had any success porting to a macOS app? I'm interested in a Chromecast solution because the devices are relatively inexpensive considering other wireless HDMI devices out there.
I am an entertainer and my goal would be to replace my HDMI cable with a wireless solution to extend my display (not mirroring the main display on my MacBook Air) to multiple TV's (up to four) for my app, which displays a game log, advertising, and some minor animation for game winners and losers that my patrons see.
Any recommended first steps to coming up with a Chromecast solution, or should I continue looking in other directions?
With the update of iOS 7.1 there is much changes in the ibeacon API for requesting, ranging beacon in the background even when app is killed or not launched, here are some of the things i observed as per the ranging for the beacons , in iPod 5th gen running with iOS 7.1
didDetermineState:(CLRegionState)state forRegion:(CLRegion *)region
doen't get called, but where as i run the same code in iPhone5 with 7.1 all the methods were getting called, its kind of a weird behaviour i'm facing,
http://www.proxima.io/blog/posts/2014-03-12-ios-7-1-ibeacon-tech-deep-dive/
as per the above link , it gives me something like there is not much update about ibeacon for the iOS7.1 in iPod 5th generation
Does any one faced this kind of same issue?
Be sure you wait up to 15 minutes to get a call to didDetermineState:(CLRegionState)state forRegion:(CLRegion *)region before you conclude it does not work. On some devices, detection cash take that long. See here. Do not expect calls to be received on both devices in a similar time frame. One may be fast and the other slow based on model and internal state.
Other tips: try rebooting both devices to put them in the same state, and verify the problem persists. Avoid running other iBeacon or Bluetooth apps simultaneously, as this can affect your test results. I do not have access to an iPod for testing, but I know other folks report (including those at the page you reference) that iPods work fine with these APIs
I use Spotify for all my music needs and was wondering if there was some way to write an app that would allow me to access the music from Spotify and slow songs down and loop portions of the songs. I am a musician, and something like this would help with practicing.
If it can be done, a brief outline of what I'd need to do would be appreciated.
Separately, would this be legal?
You'd have to write that application yourself using libspotify. However, I'm fairly certain the Terms of Service for libspotify disallow modifying the audio. I'm not sure if slowing down counts as "modifying" - that's probably a question for a lawyer.
#iKenndac is correct, but I just wanted to add that modifying the PCM stream given by libspotify is technically against the legal terms & conditions. However, if you do not redistribute such an application (ie, personal and private use only), you'd not be in any legal trouble.
(Disclaimer: I work for Spotify, but am not a lawyer)
You can use Djay for this. Djay have a function so you can play your songs in spotify at slower speed, or faster speed.The function is called key lock/ time stretching and it seems to work on mac running on OSX 10.9 or higher, iphone 4s or better, ipad 2 or nexus devices. Hopefully it will work for more devices soon. It is not the cheapest app in the world but it should work.
Here is a link to the ipad version.
djay 2 - algoriddim GmbH
iphone
djay 2 for iPhone - algoriddim GmbH
and mac
djay Pro - algoriddim GmbH
I recently downloaded a barcode reading application for my phone, an LG KU990i (AKA the Viewty) However, there's a problem that renders the application nearly useless: the Viewty has 2 cameras -- the main one, and a secondary camera located on the face of the unit -- and it is the secondary camera that is unfortunately set as the phone's default video capture device. As you can't point the secondary at anything and see what it's pointing at at the same time, it makes it a bit difficult to snap a barcode!
According to the JSR-135 spec, it is possible to specify a video capture device other than the default... if you know the device name. This does not appear to be documented anywhere on LG's Web site, nor does the JSR-135 spec describe any way of enumerating the devices on a phone... or is there? Failing that, are there any naming conventions for video devices commonly in use that LG might be using?
I've logged a ticket with LG, but as it's an old device, I don't imagine them breaking their backs in getting back to me... I should also point out that this is purely for my own curiosity so no-one here should feel obliged to break their backs either!
As far as I know there is no way to get list of all available catpure:// urls.
All urls I know:
capture://image,
capture://video
capture://devcam0
capture://devcam1
Source:
http://www.forum.nokia.com/info/sw.nokia.com/id/bc00e4ce-7df3-4527-962c-d39843a808d0/MIDP_Mobile_Media_API_Support_In_Nokia_Devices_v1_0_en.pdf.html
LG responded to my support ticket. Apparently, it's not possible to access the primary camera on the Viewty from Java, making it pretty much useless for barcode scanning. Answer reproduced here for search engines.
You support ticket has been answered. Please visit the LG Mobile Developer Network and login to check the answer at [My Page > My Tickets].
KU990i default video capture device is the secondary camera
Answer :
Hi,
KU990i have to Two camera module
differently.
Main camera using Joran chipset and
sub(front camera) using Qualcomm
chipset.
Joran chip doesn’t supported JSR135.
Therefore, we couldn’t supported to
the JSR135 using for main camera.
(it is H/W limitation)
It was inform to operator already and
we remember operator was confirm it.
So that, we only supported sub camera
for JSR135.
BR,
I have very easy question, but I simply have any idea of the answer.
I have developed a small mobile-application using java, for my nokia.
The problem is that when installed on my samsung the application simply crashed.
Then I tried on my other nokia but different model, and I didn't got the normal behavior.
So my question is, does anyone have any idea how companies that develop mobiles applications/games test their software.
Does they have to have all models for all mobiles phones??
Companies that target many phones in many countries usually only let you install the application on your phone if they recognise your handset User Agent in the HTTP headers of the request to download the .jad or .jar file.
There are multiple ways to test an application on many handsets for many mobile network operators.
From simply buying the phones, to establishing commercial parternships with handset manufacturers and mobile network operators, to having a Device Anywhere account.
I don't know if you need all models of all phones. But you will definitely need separate test (and probably different builds) for different phones regarding:
MIDP version
Screen Size
Input Devices
Speed & Memory
Java, in this case is, WOTA (Write Once Test Anywhere) instead of WORA (Write Once Run Anywhere). :-)
Phone specs and Java implementations vary a lot, but within each manufacturers range there will be groups of phones that share the same specs and implementation.
I used to work at a company making J2ME games, what we did there was test on every handset we released the game on, but we had 2 types of test - Complete and Compatability.
We would adapt a version of the game for a specific phone, eg Sony Erricson K800i, and have it thoroughly tested according to the Complete Test spec.
Once that had passed, we then used that build on phone known to have similar specs and good previous compatability with other games (we kept a database of specs and compatability records), eg Sony Erricson W910i, and submit it for a compatability test, which was a bit less thorough and a bit quicker.
Once you've been doing it a while you get to know the capabilities of phones and which phones you could use the same build on, but there is often a bit of guesswork involved :) Sometimes you get matches you wouldn't expect, and sometimes a match you would expect to work doesn't.
Edit: I was going to post this as a comment, but I can't (because i'm an SO noob :), out of interest, what phones are your Nokia's and Samsung?
I can't remember many specific handset names, but here is a quick rundown of compatability across manufacturers:
Sony Erricsons are generally excellent - if it works on one, it will likely work on all SE handsets with the same resolution.
Nokia's are generally good within a certain smaller group eg N95 builds work well on most nokias with the same res that were released after the N95, but some handsets are a bit of a pain.
Samsungs are pretty bad - the J2ME implementation on most is flawed (Hide/Show Notify methods not being called is an example), and the memory and speed are typicly a bit crap.
Motorola phones are not great, but are generally quite compatable with oneanother. Same goes for LG, although their more recent models are much better.
Testing is one of the most labour intensive part of mobile phone development. Typically a company might simply buy a lot of different phones to test on for real, or target a particular subset such only as Series 40 Nokia phones.
But alternatives exist out there where you can remotely deploy your app to phones, such as Nokia's Remote Device Access Services.
One way that might limit the problems is to target J2ME MSA (Mobile Service Architecture) compliant phones, where MSA attempts to reduce variations in vendor implementations of J2ME.