Related
While there are plenty of useful threads out there pointing out various apps, I haven't found one that listed the kinds of apps that someone who works in IT like me might find useful, hence this thread.
Hopefully others can add.
1/
ABBY Business Card Reader - A nice app to take a picture of a business card, them import it into contacts. - It is NOT 100% accurate, it DOES require user input to make corrections, but even so, it is worth the money.
2/
Snap n go - a useful little app that requires a companion app on the PC - basically use a camera to take a pic of windows explorer and touch the file to import viw wi-fi
3/
Office suite - self explanatory
4/
Gingerbread keyboard - what it says, if you type much this is the best by far.
5/
QR droid - 2D barcodes, fabulously useful, learn to use these things, you will need to sooner or later.
6/
Electrodroid - paid version - absolutely brilliant for anyone who goes anywhere near computer or electronic hardware, does far too much for me to list here, from various connector pin-outs to resistor circuit calculations.
7/
MobileBiz Pro - paid version - create quotes and send invoices from your mobile, the complete mobile billing solution, one customer will pay for this truly excellent app.
8/
PC Monitor - paid version - companion to an app run as a service on a PC, stonking app, does just about everything you could require for monitoring and controlling remote computers via GSM, including running command line, booting users, controlling services, monitoring hardware, truly excellent app.
9/
WiFi File Explorer - paid version - file manipulation and exchange between phone and any computer with wi-fi, just open a browser window on the computer. Another superb app.
Just add a 16 gig SD card and fill it with useful apps and tools, magic, never worry about which USB stick hold what again.
10/
Wifi Analyser - does what it sounds like, very useful.
11/
RF Signal tracker - does what it sounds like but for phone / radio frequencies, very useful.
12/
SetCPU - paid app - brilliant for underclocking on demand, which prolongs battery life.
13/
Network mapper - the android version of cheops etc.
14/
SMS Backup + (Jan Berkel) - does what it says on the tin.
15/
Contact Analyser 2 - stops cruft building up with contacts.
16/
GTech Net Tools - another very useful TCP test app
17/
Network Info II - another useful network info tool
18/
Terminal Emulator - does what it says on the tin
19/
GPS Survey - very useful for outdoor wi-fi
20/
Google - Mail / Maps / Navigation / Buzz, very very useful.
21/
Titanium backup - self explanatory
All of the above turn my Galaxy S into a portable office complete with customer billing, plus a portable computer / wi-fi diagnostic toolbox
I would swap 14 for SMS Backup+. It backs up the call log as well and all automatically to your Gmail account.
Tehpriest said:
I would swap 14 for SMS Backup+. It backs up the call log as well and all automatically to your Gmail account.
Click to expand...
Click to collapse
quite right too, installed on my phone now.
Thank you! Very useful app!
Nice one !
Thanks for the mention of Electrodroid, it comes in very handy in the garage, even if it does now mean my phone gets covered in grease and oil now
FlanFlinger said:
Nice one !
Thanks for the mention of Electrodroid, it comes in very handy in the garage, even if it does now mean my phone gets covered in grease and oil now
Click to expand...
Click to collapse
If you go near a car then Garage Buddy is also quite useful.
There are also some good android ODB interfaces if you have a more modern vehicle.
Hey guys, I posted this in the general section but I think it would be better to post it here. Could the Xperia Play controls be used with PC games? Even with Xpadder or something similar? What would we need to make this happen?
As I already said, you need new kernel or kernel module to enable sharing of phone's PS controls via USB.
Why via USB and not bluetooth or Wifi?
Blagus said:
As I already said, you need new kernel or kernel module to enable sharing of phone's PS controls via USB.
Click to expand...
Click to collapse
And what that does mean? xD
Miles Wolf said:
Why via USB and not bluetooth or Wifi?
And what that does mean? xD
Click to expand...
Click to collapse
I think the original poster wanted to do this via USB to have it function as a standard gamepad, like a HID compliant device. This would require new kernel modules and thereby a new kernel to use on the device (and probably an app as well).
If you wanted to generate gamepad HID codes via communications over BT or WiFi (or over USB Debug channels) data streams, you could likely do so, but would need computer side drivers and programs, as well as the program to use on the device.
This is totally do-able. However the want for doing so is up to the individual. I personally don't have much want of it, as I already have good controllers for my PC.
I think it would be possible to make such app as well, which would log keypresses and send them via Bluetooth or Wi-Fi. But additional software would be needed on PC side too. But that's an option too, which isn't bad at all. Actually, USB HID method would be, IMO, more advanced...
I've used software that lets me use my phone as a touchpad, mouse, and media playback controller for my pc. So i dont' see why it couldn't be done. that software used wifi.
ace518 said:
I've used software that lets me use my phone as a touchpad, mouse, and media playback controller for my pc. So i dont' see why it couldn't be done. that software used wifi.
Click to expand...
Click to collapse
There are a few reasons off the start. A game controller would require nearly instantaneous reaction time to work properly. Secondly, people would expect it to work nearly flawlessly with next to no work or reading on their part.
Yes, it is _TOTALLY_ do-able. However, doing it just to do it, I don't see the benefit, as I personally wouldn't use it, and I certainly wouldn't receive pay nor even praise from the community. So it fails all the tests for me to engage myself in a project. The "Benefits Me", "Benefits the larger community", and "Benefits my ego" issues. If it benefitted the larger community, maybe. However it seems the consensus is that most people have dedicated controllers already that are low cost. I don't intend to use my phone as a PC controller, as I have several game controllers (from a 360 pad, to flightsticks, to a nostromo speedpad) for my PC. I also don't currently have a need to learn the Bluetooth or WiFi stacks so this wouldn't benefit me. Lastly, any product I were to produce would have limited market, and most of the market it would be presented to would be more likely to bash it than to even click a button to say 'Thanks' for it as they download.
If somebody is interested in doing this, go for it! It would be a nice little experiment project to learn the coding requirements for using the BT stack as a HID device or forwarder, or the WiFi stack and how to coordinate with a client side device driver and program as well. Just personally I won't be doing this.
i remember on my old sony ericsson phone w810i i could control my mouse on my pc with my fone via bluetooth with a built in app called desktop remote
so now wouldnt it be better to have the control pad on the play, use BT
to play pc games etc?
ace518 said:
I've used software that lets me use my phone as a touchpad, mouse, and media playback controller for my pc. So i dont' see why it couldn't be done. that software used wifi.
Click to expand...
Click to collapse
I believe GRemote does something similar. you can use your phone as a wifi mouse and keyboard or joystick or media controller. unfortunately, its fairly expensive so not really worth it. no way i'm paying $5.00 for it.
It would be cool to see this working.
crispyduckling said:
i remember on my old sony ericsson phone w810i i could control my mouse on my pc with my fone via bluetooth with a built in app called desktop remote
so now wouldnt it be better to have the control pad on the play, use BT
to play pc games etc?
Click to expand...
Click to collapse
I remember that, haha. Unfortunately it wouldn't work very well as a gamepad, there was like a half second delay between each button press.
I doubt BT or Wi-Fi would be good, because of the mentioned delay. SE kernel sources do have USB HID driver but I don't know is it used for USB OTG or to be used as HID on PC.
Another question.
Is any App out there where i can use the Xperia Play Gamepad for another Android Devices like my HTC Flyer?
->
Start an Emulator in my Flyer and use the Xperia Play Gamepad over Bluetooth or wifi to play the Games on the Flyer.
For iOS with Jailbreak i can use a SNES Emulator on ipad and a iPhone or iPod Touch as Gamepad/Controller.
Thanks for help and answer!
Waqas said:
I believe GRemote does something similar. you can use your phone as a wifi mouse and keyboard or joystick or media controller. unfortunately, its fairly expensive so not really worth it. no way i'm paying $5.00 for it.
Click to expand...
Click to collapse
gPad does this and there is a free version which I haven't been able to discern much difference between it and the paid version.
German-Guy said:
Another question.
Is any App out there where i can use the Xperia Play Gamepad for another Android Devices like my HTC Flyer?
->
Start an Emulator in my Flyer and use the Xperia Play Gamepad over Bluetooth or wifi to play the Games on the Flyer.
For iOS with Jailbreak i can use a SNES Emulator on ipad and a iPhone or iPod Touch as Gamepad/Controller.
Thanks for help and answer!
Click to expand...
Click to collapse
yes that is what I'm wondering as well really hope it is possible.
Blagus said:
I doubt BT or Wi-Fi would be good, because of the mentioned delay. SE kernel sources do have USB HID driver but I don't know is it used for USB OTG or to be used as HID on PC.
Click to expand...
Click to collapse
The PS3 and Wii controllers use Bluetooth.
benoitb85 said:
The PS3 and Wii controllers use Bluetooth.
Click to expand...
Click to collapse
Way to necro a thread.
_YES_ they use WiFi, but they aren't multi-purpose processing devices that have other priorities and background processes. They also are dedicated to doing such actions, and are engineered with that in mind.
To get it to work on the Play, as a BT controller (or WiFi, which would be even laggier), would require a kernel module to be created and installed (meaning new ROM/Kernel and likely an app as well). Then you would need a machine that has the proper HID profile enabled via BT, or a separate app to mimic a HID USB controller via WiFi.
As said before, since this thing tends to have other priorities than _JUST_ its gamepad (data synch, OS/VM GC, memory mgmt, etc), there are times when it will lag out even with a high priority on the module and associated game-controller app.
This _IS_ possible, just nobody is as excited by the idea who would be willing to code it. Honestly, if you wanted to do it as a starter coding project for via WiFi, it would be interesting to see your take on it. If you want to get your hands dirty with coding a kernel module to offer a HID profile via BT, that would be an even more elegant solution. However, it would require a bit more advanced knowledge. I haven't written any kernel modules by hand, ever. I've only adapted existing ones and patched a few on my own machines, so I'm certainly not a candidate to go after this myself.
We are not saying it isn't possible. It is. Via WiFi it just isn't a good idea (lag), and via BT would require some more involved and in-depth modifications and coding. Getting coding to set it up as a USB attached controller would probably be a bit easier and possibly even easier to code than the BT HID stack inclusions. I encourage those who think this is a good idea to try coding it themselves. I'm sure others would be interested in it (based upon this thread).
https://play.google.com/store/apps/...rch_result#?t=W251bGwsMSwyLDEsImFwcC5wY29uIl0.
I did not try it yet.
benoitb85 said:
https://play.google.com/store/apps/...rch_result#?t=W251bGwsMSwyLDEsImFwcC5wY29uIl0.
I did not try it yet.
Click to expand...
Click to collapse
Darn it. Missed this thread before making my own. Now I feel kinda dumb. But if anybody tried this app and got it working, could you please upload the devs windows drivers/programs. Because the devs site is unavailable in my country.
Sent from my PLAYSTATION PHONE using tapatalk
Dilemina said:
Darn it. Missed this thread before making my own. Now I feel kinda dumb. But if anybody tried this app and got it working, could you please upload the devs windows drivers/programs. Because the devs site is unavailable in my country.
Sent from my PLAYSTATION PHONE using tapatalk
Click to expand...
Click to collapse
This app is amazing. But the only problems are that the X button does not work properly (you have to hold it) and the buttons can't be mapped to some keys for example SHIFT. Otherwise It helped me finish Sonic Generations
BT Tag Writer is application that offers you way to add NFC pairing to your old Bluetooth speakers. NFC pairing allows you to pair, connect and disconnect the device just by tapping the NFC tag with your phone. This application is still under development and this thread can be used to request changes and new features for this application.
Market: https://market.android.com/details?id=fi.siika.bttagwriter
Video: http://www.youtube.com/watch?v=IbuLGsXIvKI
--- original first post ---
Hello everybody.
I have been now writing application for Android devices with NFC capabilities. It basically offers wizard interface for writing new NFC connectivity tags for your Bluetooth speaker(s)/headset(s)/etc. And software that will take care of the actual pairing/connecting, when you tap the tag with your phone. NFC pairing is something Nokia does with N9 and it's Bluetooth speakers, but it looks like Android still doesn't handle this well out-of-the-box. Also I still haven't found easy to use connectivity tag writers for any devices.
Sort demo of application in it's current state: Check youtube video kzoG5VM6VcU (can't have this as a proper link, as I only have less than 8 posts to this forum, sorry)
Before I release this software to market, I would like have some people testing it with their speakers and devices. I really hate alpha level software in market. If you have Galaxy Nexus, some sort of Bluetooth speaker(s)/headset(s) and hopefully some writable NFC tags, and you would like to help me to get this software tested: Please tell it here. I still have some small things to resolve before this is ready for closed testing. If you like to help me to get this tested please also tell what sort of Bluetooth device you have and what NFC tags you have available.
I will most likely release this software as free (gratis) and probably in open source (don't know the license yet). So I am not planning stealing your time and then making money out of it. Only thing I can offer to you is to add your name to application's thanks list.
Also if you know software that already does all this, please tell. If my software does not bring anything new, I have to redesign it little bit.
Thanks.
I'd like to test your app.
Got the same NFC-Chip like you (mi(d)fire or something like that I've bought for my old Nexus S) and a Nokia BH-504 Bluetooth Headset and for sure a Galaxy Nexus and a Galaxy S, too
Just tell me how I can help testing...
i would test as well buddy!
s60mike said:
I'd like to test your app.
Got the same NFC-Chip like you (mi(d)fire or something like that I've bought for my old Nexus S) and a Nokia BH-504 Bluetooth Headset and for sure a Galaxy Nexus and a Galaxy S, too
Just tell me how I can help testing...
Click to expand...
Click to collapse
For now this is ICS software, do you happen to have some unofficial 4.0 image in those? I kinda would like to make this 4.0 only software, as all NFC devices most likely will get that update.
S suxeN said:
i would test as well buddy!
Click to expand...
Click to collapse
Your phone is Nexus S? What sort of Bluetooth devices you have, and NFC tags...
I'd love to test this. I've been using NFC Task Launcher to do something similar but it doesn't currently support connecting to a specific device. I'm running ICS on a GSM Galaxy Nexus and have several A2DP speakers I could test with.
Northernmost said:
I'd love to test this. I've been using NFC Task Launcher to do something similar but it doesn't currently support connecting to a specific device. I'm running ICS on a GSM Galaxy Nexus and have several A2DP speakers I could test with.
Click to expand...
Click to collapse
I will fix few annoying things and then will put link to debug apk-file here (maybe Wednesday). I will try to see if I can make it run in 2.3.5+ too. Anyhow software will be limited to Mifare Ultralight tags (original and C versions). I have to buy other type tags to see what I can do with those, but that's later. Common Ndef writer classes does not work at all with Android or then I'm doing something wrong.
Android also really limits clean ways to do intents for more complex tags. So these tags software now writes are not proper connectivity handover tags. Just the core part of those is used and stored as single NDEF mime item and then this app is marked to handle those NDEF messages/records. Positive side with that is of course that information fits to smaller tags. Also PIN code storing will be probably done little hacky way to the first version.
alump said:
For now this is ICS software, do you happen to have some unofficial 4.0 image in those? I kinda would like to make this 4.0 only software, as all NFC devices most likely will get that update.
Your phone is Nexus S? What sort of Bluetooth devices you have, and NFC tags...
Click to expand...
Click to collapse
Like said above. Both devices got ICS and NFC and I've got Midfire NFC Tags...
s60mike said:
Like said above. Both devices got ICS and NFC and I've got Midfire NFC Tags...
Click to expand...
Click to collapse
So many different Mifare tags out there. Mifare Classics will not work (for now).
Anyway, pushed software to market after all. In few hours you should be able to find it from there. Offer still stays, if you can try it out and report issues here it would help. I had to drop headset support for now as it didn't work as well as I hoped.
Great! Will try it out today. Here's the market link https://market.android.com/details?id=fi.siika.bttagwriter
Sent from my Galaxy Nexus using Tapatalk
alump said:
Mifare Classics will not work (for now).
Click to expand...
Click to collapse
Missed that bit. I really must learn to read All the Mifare tags I have are Classic ones.
A couple of initial thoughts after myfirst use of the app...
1) Back when I was on 2.3.7 there was a Bluetooth A2DP widget I used (can't remember the exact name now) that, when you created the widget, would display a list of already paired devices that supported the A2DP profile. Once you'd picked one the widget would attempt to connect to it automatically.
I'd like to see your app do something similar rather than having to go through a pairing process with a device I've already paired with. It's a small thing to do I know, but I'd imagine most users will have already paired with their speakers before ever finding your app. I don't know if you can enumerate paired devices supporting the A2DP profile in ICS though.
2) When your app was scanning for BT devices it would find my speakers but would only display the BT address. It didn't display the BT device name after waiting for several seconds. This may be a BT stack problem though.
3) It looks very nice!
Northernmost said:
Missed that bit. I really must learn to read All the Mifare tags I have are Classic ones.
A couple of initial thoughts after myfirst use of the app...
1) ....I'd like to see your app do something similar rather than having to go through a pairing process with a device I've already paired with...
2) When your app was scanning for BT devices it would find my speakers but would only display the BT address. It didn't display the BT device name after waiting for several seconds. This may be a BT stack problem though.
Click to expand...
Click to collapse
1. Yes my app does not trust the already known devices list. Have to see if I can get that too. Anyway my application does not pair devices that have been paired already. It simply is stupid to not offer those. I have to check if I can used paired devices list too. I have to add some indicator to list what devices are then old known and what are just found with discovery.
2. I have seen "no name" issue only once. But yes, that's "stack problem"... I hope
Anyway I think I have to try to add Mifare Classic support first.
alump said:
1. Yes my app does not trust the already known devices list. Have to see if I can get that too. Anyway my application does not pair devices that have been paired already. It simply is stupid to not offer those. I have to check if I can used paired devices list too. I have to add some indicator to list what devices are then old known and what are just found with discovery.
Click to expand...
Click to collapse
Sorry for spam, but finally this will be mine 8th post
Request to list already paired devices is now added to Market version (0.3). So no need to turn already paired devices to pairing mode when writing tags.
Support for other than ultralight Mifare tags might take some time. Thanks to keys etc those tags are not ideal for this use. I think I will try to add headset support first.
Just to confirm that 0.3 is listing my paired A2DP devices
alump said:
Your phone is Nexus S? What sort of Bluetooth devices you have, and NFC tags...
Click to expand...
Click to collapse
Nexus S, running Brainmasters ICS 4.0.3
Bluetooth devices:
2 headsets
another Xperia ArcS
NFC Tag:
dont have a tag yet, but could get some. Dunno what kind they are!
S suxeN said:
NFC Tag:
dont have a tag yet, but could get some. Dunno what kind they are!
Click to expand...
Click to collapse
My unofficial NFC tag type list (from memory, might have mistakes)
Mifare Ultralight C is my recommendation. If you plan to use this for this, or for example: storing your contact information, storing some url, storing application starter information etc.... Simple, cheap and easy to use alternative.
Mifare Ultralight (non C) is too small for almost anything. You can use it anyhow with my software (limited features) and you can fit sort URL to it.
Mifare 1K, Classic, etc... these are for more secure needs. Or if you really want to store a lot more information to the tag. For non secure usage (e.g. my app) the secure features are just annoying extra that makes things more complex. Key based security so if you mess up with key, then you can't read or replace that data anymore. Also kinda "proprietary alternative".
Felicas are Sony's alternative for all these. Probably not easy to find outside Japan. Topaz is good alternative for Ultralights, but I don't know how well Android supports those currently (haven't tested). And if Broascom/Innovision still makes these? Not too easy to find anyway. And then there are many more... it's a total mess and maybe the main reason why it's so hard for NFC to break big time.
But for the most of use cases: I assume Mifare Ultralight C is the best alternative.
NFC Tag store examples:
TagAge - I'm using this, but mainly because I live in Finland.
NFCDog - is one UK alternative.
And many more, Google search is your friend. And this message has't been paid by either of these stores
alump said:
My unofficial NFC tag type list (from memory, might have mistakes)
Mifare Ultralight C is my recommendation. If you plan to use this for this, or for example: storing your contact information, storing some url, storing application starter information etc.... Simple, cheap and easy to use alternative.
Mifare Ultralight (non C) is too small for almost anything. You can use it anyhow with my software (limited features) and you can fit sort URL to it.
Mifare 1K, Classic, etc... these are for more secure needs. Or if you really want to store a lot more information to the tag. For non secure usage (e.g. my app) the secure features are just annoying extra that makes things more complex. Key based security so if you mess up with key, then you can't read or replace that data anymore. Also kinda "proprietary alternative".
Felicas are Sony's alternative for all these. Probably not easy to find outside Japan. Topaz is good alternative for Ultralights, but I don't know how well Android supports those currently (haven't tested). And if Broascom/Innovision still makes these? Not too easy to find anyway. And then there are many more... it's a total mess and maybe the main reason why it's so hard for NFC to break big time.
But for the most of use cases: I assume Mifare Ultralight C is the best alternative.
NFC Tag store examples:
TagAge - I'm using this, but mainly because I live in Finland.
NFCDog - is one UK alternative.
And many more, Google search is your friend. And this message has't been paid by either of these stores
Click to expand...
Click to collapse
Okay, ima gonna order some and report back to u
music auto start
is there a way to make it so that my music app doesn't auto play my most recently played track when the BT connection is made ... id like for it to simply open the app
I have a Samsung Galaxy SIII and just made my first NFC-steps using some Samsung TecTiles tabs.
After trying a few NFC apps from the Google play, I have a few basic questions.
While basic functions like p.ex. switching Bluetooth are available in all apps, other functions like p.ex. showing a pop-up, text-to-speech or calendar functions are only available in only in one particular app.
Is there a predefined set of nfc-functions for any given android version or the app-author is basically free to program any function he can think of?
I tried to import a tag in one app which i previously have written with another app. This didn't always succeed. I could understand that there is a problem with importing special functions which are unknow to an app, but at least the basic tag and the basic functions should be recognised by all nfc-apps.
As the nfc-apps progress, will we see new functions/possibilities or will it stay about at the present level as the available functions are limited by android?
My device is locked, mainly because it was mandatory by a VPN installation.
Is there a way to unlock it 'automatically' thru NFC? I know this can be a security issue, but it would be so handy just p.ex. to put the phone in the car-holder and it would automatically go to the home screen or the car screen, and also during driving its annoying when the device has a time lock and needs to be unlocked in the middle of an intersection......
What is the power consumption of the nfc-module in the S3?
Thanks for your input.
Rgds
sansibar said:
I have a Samsung Galaxy SIII and just made my first NFC-steps using some Samsung TecTiles tabs.
After trying a few NFC apps from the Google play, I have a few basic questions.
While basic functions like p.ex. switching Bluetooth are available in all apps, other functions like p.ex. showing a pop-up, text-to-speech or calendar functions are only available in only in one particular app.
Click to expand...
Click to collapse
I think, I know which app you mean
Is there a predefined set of nfc-functions for any given android version or the app-author is basically free to program any function he can think of?
Click to expand...
Click to collapse
There is a set of predefined nfc-functions, (like open a webpage, vcard, open an app..) but this set is very very limited and even the mentioned Bluetooth function is not included .... in fact, bluetooth needs a little hacking, because the official api does not support to turn on bluetooth without asking the user .....so basically a developer can (/ has to!) implement every function he wants, but in reality a lot of functions are blocked on non-rooted devices, because android defined them as security related....
I tried to import a tag in one app which i previously have written with another app. This didn't always succeed. I could understand that there is a problem with importing special functions which are unknow to an app, but at least the basic tag and the basic functions should be recognised by all nfc-apps.
Click to expand...
Click to collapse
As mentioned the basic set is very limited.... it´s based on the nfc forum specifications and using nfc to control your device, is something these guys never had in mind ....so, sure you could use some standard nfc writer and write a webpage on a tag..... and this should be something every nfc device (not only android, but also blackberry, windows phone etc...) could handle .... but if you want to control your device, you need a more sophisticated app .... and there is no way to import a tag from one app to another ...
As the nfc-apps progress, will we see new functions/possibilities or will it stay about at the present level as the available functions are limited by android?
Click to expand...
Click to collapse
The functions are limited by android .... and my feeling is, that with every android update it get´s more limited! --> on Gingerbread, nfc was enabled while screen was off --> a function they skipped with ICS (ok, again, on a rooted device you could change the NFC.apk, to re-enable it) ... the last JB update declared the airplane modes as a security feature ... so no luck with airplane mode since 4.2 ...only to mention 2 examples ...don´t get me wrong, I don´t think it will stay at the present level, but it´s definitiv not in googles focus yet .... personally, I have a lot of new functions and use cases on my ToDo list, so I would say it´s just the beginning
My device is locked, mainly because it was mandatory by a VPN installation.
Is there a way to unlock it 'automatically' thru NFC? I know this can be a security issue, but it would be so handy just p.ex. to put the phone in the car-holder and it would automatically go to the home screen or the car screen, and also during driving its annoying when the device has a time lock and needs to be unlocked in the middle of an intersection......
Click to expand...
Click to collapse
yep, but again some hacking is envolved ... root your phone, change the nfc.apk, etc. ...I think there are several threads regarding this topic available ....
EDIT: Link added: http://forum.xda-developers.com/showthread.php?t=1853721
What is the power consumption of the nfc-module in the S3?
Click to expand...
Click to collapse
Forget it .... it doesn´t make a significant difference, if you have NFC enabled or disabled ....
Thanks for your input.
Rgds
Click to expand...
Click to collapse
no problem
Oh hay there,
I've been tasked with making an app for windows 8, that has to fulfill the following specifications.
I've been wondering weather i should use the win RT (metro API) or the windows presentation foundation (WPF) API to do it.
requirements:
Needs to be fast (winRT has a slight edge here due to Ahead of Time compilation, but WPF can be compiled ahead of time too)
Needs to be optimized for touch (it's a draw here, WPF can be made touch friendly and supported touch from day one)
Needs to be able to communicate in background with a number of sensors (WPF has the edge here, as it can access low-level OS components, and is also not restricted should it go to the background)
Needs to be easily modified to support new technologies (This one is a bit tougher. Modifying a winRT app takes a while, it needs around 7 days just to process certification, while an update to WPF can be delivered right away. On the other hand, winRT will probably have high level APIs to handle new technologies, whereas WPF will likely be stuck with the lower end of the API, which will make it harder to modify, especially to those not familiar with windows/.net architecture.)
Needs to run on tablet (WinRT has the edge, as it can run on arm-based tablets as well).
Needs to communicate via NFC, get GPS coordinates and take pictures (WPF can do this, but again, it has lower level APIs, which might be hard to adapt in the future)
Needs to be resilient to outside tampering (virus, trojan, malware etc)(WPF is not 100% sandboxed, it has nice runtime security, but the files it creates are not protected, winRT has the edge here)
I need some opinions. I will make my own decision, but I would like to hear some of your opinions first.
Don't ask what the app does, I'm not gonna tell you.
One thing that immediately stands out, GPS. Is this using the tablets integral GPS, a USB unit or a serial/bluetooth unit? If its not integral or USB (and even then, some USB ones are USB>serial adaptors followed by a serial unit) then WinRT wont function with it. You dont get any access to serial ports, parallel ports or the onboard i2c interface via WinRT. Everything is a higher level abstraction wrapping up low level functionality, you get not raw access to it yourself. Most of these tablets out will be using a serial GPS as that is what is most common (or possibly an i2c one but thats something I have never seen before) and WinRT will provide a nice set of wrappers to let you interface with the integral GPS only, but it wont give access to the serial port or the bluetooth serial profile which means it will ignore bluetooth, external serial or certain USB GPS devices. So yes, WPF would certainly have the edge there. But if we are just talking the GPS chip built into the tablet, WinRT will suffice and provides easy access to all onboard sensors, its only external ones that will cause headaches.
WinRT vs regular .NET speed wise likely wont make much difference. I'm not sure that WinRT is fully AoT dependant for its apps (except C/C++), I think it still falls back on .NET, and even if it is AoT the .NET JIT is almost as effective (and with some kludging can be set to AoT I think, mono certainly can and can cope with WPF applications).
I dont own a tablet so cant say too much on touch, I have only handled display model tablets. Tbh, I found most desktop apps annoying on tablets. even if you enlarge buttons and fonts to make them more touch friendly you can run into additional issues, a menu thats too long to fit on screen cant necessarily be scrolled with a touch friendly gesture (well, you can try, but your probably going to have to write some of your own code, might not be that hard actually, I havent tried). If the app is purely meant for touch then I would go WinRT unless there is a specific reason not to.
Updating taking 7 days I dont see as a major problem, everyone else does it and on numerous platforms. It may well take 1 day to integrate a new tech into a WinRT app and 2 weeks on the WPF app in which case the WinRT guys still get the new tech before WPF, or vice versa is equally likely.
NFC communications, GPS and cameras are all easily done in WinRT (with the previous restriction, device only, non external, I assume a webcam works though).
WinRT is probably the more secure option too.
If I were you I would write down each little thing the app needs to do in order to function, ie access a specific type of GPS (you already said you wont share, thats fine). Then go down the list and start ticking off which ones WinRT has the technology to do. We can pretty much assume that eventually WPF will also do it so there is little reason for a WPF checklist. If you get to the bottom of the list and WinRT is fully ticked off, then go with a WinRT app. If there are a few things missing, well then start to weigh up whether it would be better to try and get a WPF app playing nicely with touch and implementing a few things at a lower level or alter the design specification to fit WinRT, I assume there is a client involved here, if there are issues sit down with them and discuss your thoughts and see if they are happy with changes to go one way or the other.
SixSixSevenSeven said:
One thing that immediately stands out, GPS. Is this using the tablets integral GPS, a USB unit or a serial/bluetooth unit? If its not integral or USB (and even then, some USB ones are USB>serial adaptors followed by a serial unit) then WinRT wont function with it. You dont get any access to serial ports, parallel ports or the onboard i2c interface via WinRT. Everything is a higher level abstraction wrapping up low level functionality, you get not raw access to it yourself. Most of these tablets out will be using a serial GPS as that is what is most common (or possibly an i2c one but thats something I have never seen before) and WinRT will provide a nice set of wrappers to let you interface with the integral GPS only, but it wont give access to the serial port or the bluetooth serial profile which means it will ignore bluetooth, external serial or certain USB GPS devices. So yes, WPF would certainly have the edge there. But if we are just talking the GPS chip built into the tablet, WinRT will suffice and provides easy access to all onboard sensors, its only external ones that will cause headaches.
WinRT vs regular .NET speed wise likely wont make much difference. I'm not sure that WinRT is fully AoT dependant for its apps (except C/C++), I think it still falls back on .NET, and even if it is AoT the .NET JIT is almost as effective (and with some kludging can be set to AoT I think, mono certainly can and can cope with WPF applications).
I dont own a tablet so cant say too much on touch, I have only handled display model tablets. Tbh, I found most desktop apps annoying on tablets. even if you enlarge buttons and fonts to make them more touch friendly you can run into additional issues, a menu thats too long to fit on screen cant necessarily be scrolled with a touch friendly gesture (well, you can try, but your probably going to have to write some of your own code, might not be that hard actually, I havent tried). If the app is purely meant for touch then I would go WinRT unless there is a specific reason not to.
Updating taking 7 days I dont see as a major problem, everyone else does it and on numerous platforms. It may well take 1 day to integrate a new tech into a WinRT app and 2 weeks on the WPF app in which case the WinRT guys still get the new tech before WPF, or vice versa is equally likely.
NFC communications, GPS and cameras are all easily done in WinRT (with the previous restriction, device only, non external, I assume a webcam works though).
WinRT is probably the more secure option too.
If I were you I would write down each little thing the app needs to do in order to function, ie access a specific type of GPS (you already said you wont share, thats fine). Then go down the list and start ticking off which ones WinRT has the technology to do. We can pretty much assume that eventually WPF will also do it so there is little reason for a WPF checklist. If you get to the bottom of the list and WinRT is fully ticked off, then go with a WinRT app. If there are a few things missing, well then start to weigh up whether it would be better to try and get a WPF app playing nicely with touch and implementing a few things at a lower level or alter the design specification to fit WinRT, I assume there is a client involved here, if there are issues sit down with them and discuss your thoughts and see if they are happy with changes to go one way or the other.
Click to expand...
Click to collapse
Thanks for the response
The tablet picked for this job has the following minimum requirements:
Intel z2760 atom processor (apparently, they prefer x86 over ARM)
2 GB of RAM
NFC, GPS, Bluetooth (integrated, as in the tablet has no external USB adapted sensors or something)
mini USB
front camera 2 MP
back camera 8 MP
64GB storage
It's basicaly an asus vivo tab smart.
I suppose the GPS and NFC are built in. I haven't developed much with winRT, so i don't know all the ins and outs.
Btw, did Mono get WPF working? Last time I checked they said WPF was too large scale for them to port.
mcosmin222 said:
Thanks for the response
The tablet picked for this job has the following minimum requirements:
Intel z2760 atom processor (apparently, they prefer x86 over ARM)
2 GB of RAM
NFC, GPS, Bluetooth (integrated, as in the tablet has no external USB adapted sensors or something)
mini USB
front camera 2 MP
back camera 8 MP
64GB storage
It's basicaly an asus vivo tab smart.
I suppose the GPS and NFC are built in. I haven't developed much with winRT, so i don't know all the ins and outs.
Btw, did Mono get WPF working? Last time I checked they said WPF was too large scale for them to port.
Click to expand...
Click to collapse
I think mono on windows gets WPF as it can fall back on the live already there, they haven't got a Linux or mac version for sure though, only winforms although there is a 3rd party lib that gives a few controls which look very much like the WPF counterparts which should work on mono. Or there are .net bindings of QT and GTK.
If its the integral GPS as you say, WinRT should cope absolutely fine. Did some more googling and it seems WinRT will only recognise GPS device with an actual device manager entry, that is what discounts serial devices, it may actually be possible to give a serial device a kick up the backside so its listed in device manager alongside the integrated one but in your case its not needed.
SixSixSevenSeven said:
I think mono on windows gets WPF as it can fall back on the live already there, they haven't got a Linux or mac version for sure though, only winforms although there is a 3rd party lib that gives a few controls which look very much like the WPF counterparts which should work on mono. Or there are .net bindings of QT and GTK.
If its the integral GPS as you say, WinRT should cope absolutely fine. Did some more googling and it seems WinRT will only recognise GPS device with an actual device manager entry, that is what discounts serial devices, it may actually be possible to give a serial device a kick up the backside so its listed in device manager alongside the integrated one but in your case its not needed.
Click to expand...
Click to collapse
Well I heard 8.1 gives winRT extended device driver capabilities.
Maybe it will work fine by then...
SixSixSevenSeven said:
I think mono on windows gets WPF as it can fall back on the live already there, they haven't got a Linux or mac version for sure though, only winforms although there is a 3rd party lib that gives a few controls which look very much like the WPF counterparts which should work on mono. Or there are .net bindings of QT and GTK.
If its the integral GPS as you say, WinRT should cope absolutely fine. Did some more googling and it seems WinRT will only recognise GPS device with an actual device manager entry, that is what discounts serial devices, it may actually be possible to give a serial device a kick up the backside so its listed in device manager alongside the integrated one but in your case its not needed.
Click to expand...
Click to collapse
Well, we decided to go for WPF^^
mcosmin222 said:
Well, we decided to go for WPF^^
Click to expand...
Click to collapse
Well, if microsoft gets something right, that is the .net framework.
Kinda funny I can actually call winRT assemblies from WPF(non UI ones ofc).