Related
Hi, my name is Eric. I've been working with WinCE for a long time (since WinCE 2.0 haha) and I've regained interest in PPC programming. Working with few things here and there, mostly experimenting.
In anycase, I've got an idea to record g forces on a vehicle while it's being tested to its limits (AutoX, drag race).
Now, I know there's already a piece of software out there, gPC, but it isn't completely refined (indepth calibration, angle corrections) or completely free (by donation).
The goal of the project is to create something similar to a device called gTech which goes upwards of $300 for the basic model.
Key features will include:
- a reset function + algorithms to compensate for device orientation
- graphs of resulting logged data
- logging of calibrated data and raw data
- Driving aids
- Flashing screen to indicate reaching of new peak G (separate indicators for forward and lateral)
- a screen showing realtime overlapping graphed data for all axis
- a 2d grid with a cursor indicating current forward and lateral g
- on the same 2d graph, a drawn boundary indicating limits of g achieved (this will eventually look like an egg after working the car hard)
- and finally, real time telemetry transmission via edge/3g to a receiving computer
The ultimate goal of this project is to provide reliable data for motor enthusiasts whether they would like to see if their shifting is smooth, or if they're braking, or powering on in the right places or if their car mods have had any effect (this last one is pretty useful to quantify). In addition, provide some rudimentary tools to assist in competitions and spirited driving in the form of g limit warnings (flashing screen, large indicators of current g). In the case of spirited driving on a mountain road, the device can warn when approaching loss of traction (after collecting limit data) to prevent going off a cliff.
Venues of use:
Auto Cross
Track Days
Drag Strip
Skidpad
Of course, I have to insert here, that this device can't save your bacon if you do something idiotic and by no means do I condone dangerous driving.
With that said, all the above is what I hope to achieve and any of your comments is well appreciated.
Current Release:
v0.1
Alpha stage, rudimentary raw data output via numbers and a line (indicating X and Y recorded g) and a circle (indicating Z g). The numbers shown are the raw numbers recorded from the accelerometer and not converted to m/s^2. Although, you can probably do that math on your own if you're smart enough (simple scaling). What I've discovered is that each accelerometer is different, and even going from a negative axis (eg, device upside down) to positive axis (device right side up) will give different numbers. In addition, if you run the program, you'll notice a lot of jitteriness. I hope it doesn't affect the accuracy once I smooth them out with a segmented average.
Executable is packaged in a zip. It contains an EXE which can be straight run with Dot NET CF v2.0 (basically, all WM 6.1 devices)
Hi Canagan,
Great idea, I will certainly be testing this out.
I would like to ask, would it be possible to be able to include 1/4 mile time, and 0-60 etc so we can work out HP of the car. There is a similar app for the Iphone called Dynolicious http://gizmodo.com/5030749/iphone-apps-we-like-dynolicious-car-performance-meter
Thanks.
Whoooaaa sound a really good app ! Will test it this weekend ! Thanks
PooleyUK said:
I would like to ask, would it be possible to be able to include 1/4 mile time, and 0-60 etc so we can work out HP of the car. There is a similar app for the Iphone called Dynolicious http://gizmodo.com/5030749/iphone-apps-we-like-dynolicious-car-performance-meter
Click to expand...
Click to collapse
Yes, I can do that if there's more of a demand for it. Calculating horsepower is fairly simple, however, I may put 1/4 mile times and 0-60 towards the end of development as they require tieing into the GPS.
Great idea.. I will test it also
It seemt to be working on my Touch HD. But are the meaning of all these numbers??
CanaganD said:
Yes, I can do that if there's more of a demand for it. Calculating horsepower is fairly simple, however, I may put 1/4 mile times and 0-60 towards the end of development as they require tieing into the GPS.
Click to expand...
Click to collapse
Cool, looking forward to seeing this develop.
So far the accelerator test seems to be working fine.
would be need ive i could see how many hp mycar has
Hey all,
I've been searching for techniques people use to make transparent controls. The problem with windows mobile is that windows always have the CLIPCHILDREN window style set. So you can't grab the contents of the parent window (in WM_ERASEBKGND for example) because it isn't there.
One technique would be to have the parent pass the handle of the background DC it uses to the child control but that involves having a memory DC around all the time. And if the child control is covering any sibling controls you'd be out of luck as well.
Another solution I've read about is to temporarily hide the child window so the parent window is forced to redraw the parts that would normally be obscured by the control. I personally do not like this approach. (the drawbacks are also discussed on some MS forum, i'm not allowed to post outside links yet, google for "Rounded Buttons : Does any one see any problems with this method" and you will find it)
So, there are ways to achieve what I'm looking for but they are far from optimal. Just wondering what everybody else is doing to achieve this.
The responses in that thread are pretty much spot on (funny to find I know over half the posters in that thread by reputation).
If you want to do this well, you really need to draw your own stuff, making a complete custom UI.
There is no proper way to do this in Windows Mobile (without runtime kernel patching, that is ).
Chainfire said:
The responses in that thread are pretty much spot on (funny to find I know over half the posters in that thread by reputation).
If you want to do this well, you really need to draw your own stuff, making a complete custom UI.
There is no proper way to do this in Windows Mobile (without runtime kernel patching, that is ).
Click to expand...
Click to collapse
What do you mean by "drawing your own stuff"? I am drawing everything myself now in all control i made using AlpheBlend() where needed. But that still doesn't resolve the background issue. Or are you referring to just drawing everything in a single WM_PAINT handler and only having one screen DC?
PegNosePete said:
What do you mean by "drawing your own stuff"? I am drawing everything myself now in all control i made using AlpheBlend() where needed. But that still doesn't resolve the background issue. Or are you referring to just drawing everything in a single WM_PAINT handler and only having one screen DC?
Click to expand...
Click to collapse
Well the method I use in my own new UI's is indeed per form (excluding WinAPI controls like edit boxes and such) draw using only one DC.
The problem is that any 'windowed' control, the parent will not draw to the DC if a 'windowed' control overlaps. Due to CLIPCHILDREN all data drawn to that position is simply lost.
Now, handling WM_PAINT you can get the entire update region, which tells you which parts of your form have to be redrawn. You must use this information, because blitting the entire form is very slow!
In essence, to do this right you well end up faking most of the GDI system, including your own 'fake' child windows, invalidating and revalidating portions, calculating the intersections of your 'fake' invalidated regions of the screen with the update region you get in WM_PAINT and redrawing those parts.
There are several different strategies to go about this, one is to redraw on demand, another one is to use double buffering.
I personally mostly use the double buffering technique, as this easily provides every 'fake' control with a bitmap of it's own region. A child control can then alphablend using the parent's buffer as one of the alphablend sources.
You can of course combine this with keeping state information whether a child, grandchild, etc is using alpha / transparency and this with an algorithm deciding which control needs double buffering or can draw on-demand, which can give both speed and memory use advantages. In a lot of situations you can then suffice with only double buffering the 'top' component (form) and a select number of child components.
Of course two drawbacks of per-control double buffering are speed and memory use. You can eliminate the complete-form double buffer with some smart coding and calculating. This will give you a slight speed and memory advantage. Memory use is high because many of your controls will have a copy of their current state.
This can be as complicated, feature-filled, fast and efficient as you are willing to make it. The better you can design the code the better it will work, but it is not a trivial task. There are many ways to go at this, no one way is definitely better than the other ways. It depends on what your applications does with it's display, how simple you are drawing (are you making a simple white background, or a background based on images for example gradient?), which method is more efficient.
The other method is getting the update region and actually perform redrawing of those invalidated sections (instead of copying from buffer). I can tell you from experience that if you are using image backgrounds and alphablend calls, this will be _much_ slower than double buffering (if done right).
I know all of this probaby makes little sense, I'm not a hero with explaining things ... you really have to figure this out for yourself, I guess.
Other advantages of building your own UI system are that if you do it smartly and buffering, it is very easy to port to directdraw, and possibly even GL. But I must warn you, on far the most devices actually using directdraw for this stuff is not much faster, it is in fact hardly noticable. If you manage to make a GL port, that can especially on older HTC devices (pre-HD2) be much faster.
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
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).
I posted this in the galaxy note 12.2 forums but since a lot of us use mice on the shield TV I thought it might help someone here.
Gaming Mice on Android
I'm not sure if anyone else uses a gaming mouse but I thought I would note that while I haven't found a way to configure a gaming mouse in android, you can still use any gaming mouse with onboard memory.
you just program it on your PC and then when you plug it into the android tablet (or any other android device) and all of your key pre-sets and lighting presets are there.
This is useful for people that remote into their work computers from home, or just want easy copy paste functionality or for the people that remote into their computers for gaming etc.
Personally I use a gaming mouse (Razer Naga Chroma) for work on a windows 7 workstation but I use my Galaxy note 12.2 exclusively at home with no access to windows.
The Razer Naga and Logitech G600 have a scroll wheel that tilts left and right and the function can be reprogrammed.
I reassign those to copy and paste and its way faster than using the keyboard and saves some wrist strain.
I also have shortcuts for our proprietary software programmed onto the side buttons and having access to that from home is a HUGE timesaver.
now when I work from home I can have everything at my fingertips instead of having to use the onscreen windows functions in teamviewer, or digging through menus in company software.
and a lot of the normal functions carry over to android pretty well (Copy paste is much smoother from the mouse etc.)
Anyways for anyone that this might help these are the ones I've tried so far:
Works:
Logitech G600 (Supports keyboard/mouse functions and simple hotkeys like alt + Shift + Tab but does not support complex macros to device memory)
Roccat Nyth (Supports everything including complex macros but does have a length limit)
Anything with onboard memory will likely also work to varying degrees.
Doesnt work beyond default buttons:
Anything with no onboard memory:
Any mouse designed to work with Razer Synapse 2.0
Lower end Logitech mice. (Some lower end models lack onboard memory)
mice can't touch action in android app&game
leasing said:
mice can't touch action in android app&game
Click to expand...
Click to collapse
Its true, with a mice, some apps work some apps dont, this is on full android, not sure what the situation is with stock
Android/shield does this neat thing it seems, where it makes every individual app create/declare mouse support, individually, instead of, i dont know, lets say, for an example, tie mouse support with the touch system in some fashion, on the OS level, you know, so that EVERY app works, without having to rely on every app with various degrees of dev support to include or update in the mouse support.........totally neat way of doing it
implementation fragmentation
Theres also the permission implementation im starting to notice now.........marshmellow it seems has implemented a rather NEAT storage persmission decleration requirement, whereas apps running on marshmellow have to declare storage permission in order to be granted storage permission.........good idea...(sporadic sarcasm off)...no, really, security effort :good:....(sporadic sarcasm on again), ......but, but, bad implementation, you've now declared older apps with no current dev support, that still fit a function, from working on the newest android version, and perhaps, then onwards..........if the app does not declare it seems, then it simply will not work, if it requires this particular storage access.........you've just isolated a good portion of older unsurported apps that still may serve a function
I dont see why they implemented this, mmmm... in this way(CANT.SENTENCE.PROPERLY), why make the requirement, for apps to declare this, when they should have attempted to secure it, and rightly so on this front, on the bleeming OS level.............all apps would have this storage permission in android settings somewhere, and you'd simply allow or deny, on the *OS level* (record, meet hammer), much :silly:
Anyways, continuation, where was i, ah yes
",on the *OS level*",..... without having to alienate older apps with no prospects for an update
Sorry for offtopic, suspiciously rantish, like behaviour :silly:
Edit: and silly,.....yep.....silly............. i always forget that one (insert scratch head emoji)
To Recap
OS LEVEL
Razer naga works
I was able to get my razer naga to work with the shield you just have to make some adjustments to it first. You have to plug it in to your pc, install synapse, open synapse, go into the performance tab, change the dpi to 800 and the polling rate to 125 hz. The settings are saved on the device itself so you can simply plug the mouse in to the shield now and it works. You might be able to play around with dpi settings to see what works but I'm fairly certain the main issue is the polling rate. I'm going to mess around one of their keyboards to make sure it works too.