I look for a starting step to count PVC cards(let's say credit cards) with Open CV. I thought that it's possible to count lines when many cards stand as contiguous. My idea to develop this project with rasperry pi to develop a portable device. I'm very new at open cv. What could be your advices? Are there any ready solution?
Related
I have been using java since JDK 1.1. Few days before I purchased one cheap Chinese Java enabled mobile for a mere US $ 33. I started learning midlets programing. After few small midlets I started to work on real geiger counter using mobile.
There are already many android apps on internet which use mobiles camera for this purpose. When camera lens is covered with black tape light can not pass through. But if any radioactive sample is kept near camera, beta and gamma rays pass through and camera sensors give some reading. Although you can not see picture, from alpha, r, g. b values you can co-relate actual accumulated dose. My idea is to take atleast 4 snapshots per second and take the average reading of 240 photos per minute to get a correct reading.
But this app needs permission to take snapshots and also I need write permissions, So, I have to sign this digitaly.
I came to know that min. charges for digital certificate from Thwate is US $ 129/- per annum and that of Verisign is US $ 331 per annum.
Unfortunately, My phone does not have any facility to add other root certificates as GoDaddy is giving certificates for only US $ 19 per annum.
Instead of spending so much, it's better to get Android mobile which I can get around US $ 90/- (MicroMax A 50). I have made sure that android apps can be self signed.
But before leaving J2ME for this reason, I would like to know if there is any way to run self signed apps.
I think all the J2ME developers should pressure Oracle to come out with a Java VM which will allow self signed midlets. ( Any way app is asking permission to the user )
Some mobiles supports adding self signed.It is vendor and model dependent.
In Nokia s60 devices we can add self signed certificates which is used to sign midlet.
Nokia s40 device does not support self signed certificate.
Better you visit the vendor's website for further details
i am developing a application which contains many images which appear on different buttons click and has an mp3 file too..When i checked the size of my .app file it is around 6.8 mb which i think might be too large?? is there any way i can reduce the size of my .app file though i think reducing the size of my images(already around 15kb) wont be the solution.
6.8mb is fine and is small enough that people can downloaded it over 3G (the limit is 20Mb; you need wifi if it's more)
One thing to keep in mind is sales! On any app you do now or in the future you will want to keep the total size under 20mb.
Think about how many users want to "instinctively buy" your app. They saw a friend with your app and want to download it right then and there, but ohh wait... cant do it till ya get home! LOST SALE - More than likely that person will forget by the time they get home.
In your case 6.8mb is nothing compared to many apps that are games. I've seen 200 - 300mb apps that take a while to download on wifi. (WSOP Poker , Gamebox)
Good Luck my friend!
Short of a) using a real device, or b) exporting/importing contacts via SD card ... then creating the SD card 'file' for the emulator, and importing it after each emulator launch ... is there a more turnkey (saner) way to get a set of sample contacts onto the emulator for test purposes?
Easier than I thought! Whew.
When creating your Android Virtual Device (AVD), be sure to create a SD card of nominal size. (I used 20MB, which is plenty big for my purposes.) That's it in a nutshell.
Start the AVD, launch Contacts, tap Menu and create a few. When you close the AVD and launch next time, the contacts are still visible. Same thing goes for email accounts.
I was trying to compare the three above mentioned platforms and what considerations one needs to think about when programming in order to create some kind of code base that could run on all three.
This is what I have collected for the iPhone - it would be great if somebody else could write something similar for the other two.
Only one application can run at any
given time. i.e. that is why the
SQLLite database is loaded as a file
into the app instead of as
traditionally having some kind of
server to connect to.
Only one fixed size window 480x320
pixels
Runs in a sandbox, when the app is
deployed a sandbox is created
"around" the app, the app can only
read/write files from within that
area. Also low-level access to the
phone is restricted.
Since a program can be stopped at
any time (see point 1) this needs to
be considered when designing the
app, at any time must the app be
able to write its current state to
disk so that it can resume later. If
this takes longer than five seconds
the app will be aborted.
128MB RAM, about half of that 64MB
is available to the app. There is
typicall 4GB storage (depends on
model), no virtual memory, if memory
is running out the app may be
aborted.
Edit: just to be clear, I am not after which platform/os is best for the developer, I am just interested in spec. comparison to know what can be expected if one has three target platforms and using native language for each (not web apps), what the memory and other considerations are.
Edit: removed language as its assumed that native language for the platform will be used.
There is an excellent article on Codeproject which would be of benefit to your question. Head on over here to read it.
Hope this helps,
Best regards,
Tom.
For Windows Mobile I want to add:
Windows Mobile in comparison to iPhone allows multiple applications to run at same time.
It comes with variable screen sizes and has different sdks (
Windows Mobile Professional for 'Windows Phones' (smartphones) with touchscreens and
Windows Mobile Standard for 'Windows Phones' with regular screens)
The framework which is generally used is .Net Compact Framework besides some people also prefer open-net which is a open source framework.
Unlike in iPhone, Windows Mobile has no private api's which means it gives more power to developers.
The memory size allowed for a program is 32 mb
You do not need a developer license for developing and shipping applications on windows mobile although windows mobile itself prompts you to avoid installing apllications which are from unknown publishers.( which is more interesting unlike in iPhone you need to have a license while you only want to debug your applcation on your device(not for the jailbroken devices.))
And for some bad things about windows mobile, see this link.
Thanks,
Madhup
I feel like the final list will be of little use, as all data points collected will differ substantially in content apart from your last one. Some corrections to your iPhone list:
1) Local databases such as SQLLite are"not traditionally" implemented as a server on other mobile platforms either (they also use various file-oriented DB's).
2) Very soon that single fixed size assumption may well be inaccurate.
3) The App is in a sandbox but can write to some areas outside of the sandbox via API calls (for instance, photo library or address book).
5) That number varies between 3Gs and 3G/2G/Touch (the older models have half the memory)
6) Monotouch is available, but I'm not sure there's anything that far along for Java based iPhone development. There's also a Flash compiler from Adobe.
Basically if you are thinking cross platform, memory/screen size/system access/common databases will all differ - so the whole thing boils down to language AND LIBRARIES. And that is where you really have an issue with a cross-platform approach, because the libraries are very different per system... in the end you MIGHT be able to share data structures and some pure data processing code across the platform binaries, with very different GUI code for each system. But is it really worth it to constrain the development of each client?
On a side-note Blackberry is Java-based, so it presents yet another hurdle for such an attempt.
If you really want to see what cross platform ends up looking like, take a look at the codebase for Waze - a cross-platform open source navigation app:
http://www.waze.com/wiki/index.php/Source_code
Client source for iPhone and Windows Mobile lives there.
I finished building an app that allows beaming of photos, contacts and text clips over Wi-Fi
IPhone to IPhone and IPhone to desktop.
I want to decide on the feature set of the lite version of my IPhone app. I also want to come up with a pricing model. So the question is, which of these components should be free, and for which I should be charging for ?
For example, the lite version could have all features except the ability to interact with the desktop version - that is, it would work IPhone to IPhone, but not IPhone to desktop. The paid version would be able to beam to the desktop. In addition, the desktop version would be free, so you could share it with family and friends.
Alternatively, there would be a single free IPhone version and I would charge for the desktop app. The only thing here is that I would have to setup server side code for managing registration codes.
One reason to make your desktop app free and the iPhone app a paid product would be to take advantage of Apple's app store and their payment processing, hosting, etc. While I know 30% seems steep for what Apple provides, it is nice to have that part of the business be handled by someone else. For example, you will never have to deal with credit card processing or have to issue refunds - Apple does all that for you.
I like the mechanism that is more suited to viral distribution and giving people a good taste of all the features, before they are sort of convinced to go for the paid version. The marketing value of an app that can be freely tried out once one user recommends it to another, is invaluable. If someone recommends a product to me and I have to pay for it, then I probably would put off trying it till alter when I have learned more about it. However, if it is free, I can download and try it without feeling like I need to do more research prior. Once I like, and am hooked on it, then I will want locked functionality that I would have to pay to unlock.
I'd stay away from selling, payment processing, and reg code management, if your expertise is in coding - you'd make yourself more money writing more code than writing reg code management utilities...
Good luck.
I'm not sure charging for either is the best idea. If you keep both tools free, you get people trying (and liking) both apps. Viral distribution will ensure a decent user base. Once people use both tools, they're more likely to pay for the next part, which is the connector software.
I like your idea of three parts: a free iPhone app (Let people share photos on their iPhone), free PC app (There are hundreds of photo viewing apps, free... Don't try to charge for them, that way lies pain) and paid connection between 'em.
That way:
You get people using your iPhone app virally (To share with each other's phones & try out the application)
You get people using your PC app virally (Because the cost to try is nearly null)
The connection can be sold through Apple's iStore, so you don't need to do the money handling side
You could even make the connection component a subscription, but as an end user I hate that idea unless I get some additional functionality from it being a subscription (Like free hosting).