I am tasked to develop applications on a iPhone 5. However due to some office workspace restriction, we are not allowed to insert a sim card into a iPhone 5. (we will be using wifi for development)
Is there any difference in terms of software development (certain api restriction, or computability issues) that a developer may face if he/she is to develop a iPhone 5 application on a iPod touch. I'm trying to justify reasons to get a iPhone 5 :P
I've noted that GPS chipset is not available on a iPod Touch 5g, however wifi triangulation is workign for iPod touch 5g?
You can't test offline GPS navigation and cellular network on iPod Touch.
And mostly they are weaker than their phone counterparts, so you can optimize it on a weaker device, and it will more likely to run smooth on more powerful devices.
Related
I am developing an app that controls a product's operation. The communication is via BLE. My configuration is
App - Peripheral (iOS, Android)
Product - Central (uses Laird BT900 module)
iOS as a peripheral works fine (pairing and bonding) ; Android PIN pairing works fine, but subsequent bonding (or reconnect when in range) there are a lot of issues and termination of connection. I am using the supported list of devices for Android BLE and I also understand that there are many known issues that come with different manufacturers/chipset vendors
The issue I am getting is, as seen by nrfConnect, is with descriptors. Android app doesnt show descriptors when seen in nrfConnect whereas iOS shows. I do not know what is the difference
Is it a common practice to use a phone as a peripheral ? Or is it a risk - because this is a medical device.
Are there any best practices for Android as a peripheral ?
I have following back up plans in case Android issue is not resolved. I think following would work on any BLE supported phones without having any issues with the variability.
Plan A : PIN pairing on every connection with the product. This is the most secure and most annoying
Plan B : Implement just works pairing with a app layer password before taking control of the product.
Question : Is just works safe and encrypted ? Is it snoop-safe or MITM-safe ?
Thanks in advance!
A few thoughts from your questions:
1a. (From my Android experience) I think its uncommon to have the phone be the peripheral. To my knowledge all iOS devices support peripheral mode but only a very small subset of Android devices are able to support it. I say this because I've been experimenting with BTLE beacons using the AltBeacon library. From this work I have discovered that only certain Android phones can broadcast BTLE advertise packets. Given that BTLE advertising is the first step in initiating a BTLE session I imagine that this prevents many Android phones from being compatible with peripheral mode.
If all of your users can use an iOS device, then you're set, otherwise this may be a problem.
1b) I can't speak to the specific risk of using a mobile device with your medical device, that depends on what the medical device is doing and how you're using the mobile app.
2) See 1a
3) The specific encryption scheme you used is also based on your product's risk profile. I would say that Just Works is not an ideal solution. The just works pairing process is not snoop-safe and can be re-initiated via a MITM. Other than that I can't speak to the strength of BTLE encryption.
if i want to develop own my iBeacon services in Android or IOS, it has to be practical. which means customer can use my services without shortage of battery.
i think even if iBeacon technology is based on Bluetooth Low Energy, it could be still lack of battery. that's because an application must be running to scan iBeacon device all the time.
As i know, iOS has its own solution for battery issue. when an IOS application detect iBeacon devices, it is running in the background and IOS(not app) is scanning specific UUIDs by itself, not the all UUIDs nearby. this is how they save energy. am i right?
but in case of Android, any solution for battery issue is not provided. what's more,
when an Android application detects iBeacon devices, it scans all the UUIDs nearby and it deals with everything, not the Android OS. is this right?
so Im worry about this battery problems, before i start to develop own my services.
is it gonna be ok with battery?
is there any good solution to share?? how do you guys solve this problem??
The Pro version of the Android iBeacon Library comes with an automatic battery saver that slows down scans when the app is in the background to save battery. The open source Android iBeacon Library also allows configuration of a foreground and background bluetooth scan rate, and provides methods to call to tell the library when the app is in the foreground and the background.
On iOS the battery saving strategy is similar. When no app is ranging for iBeacons in the foreground, bluetooth scans are not performed constantly. The exact frequency of background scans is not published, but I have measured it happening once every 15 minutes on a iPhone 4S with iOS 7.1.
Scanning for specific UUIDs has no effect on battery life. At the OS-level, a Bluetooth LE scan looks for any Bluetooth LE device that is advertising regardless of whether it is an iBeacon or whether it has a specific UUID. The filter for specific UUIDs is handled in software at a higher level.
I would like to run and test P2P connectivity over Bluetooth via Game Center (GKPeerPickerController). I own an iPod Touch with OS 4.1 installed and am trying to connect it to the iPhone Simulator running on my Mac via Bluetooth, however they are not seeing one another. Bluetooth is on for the iPod and the Mac. Is this even possible? If so, what am I missing?
I dont think it is possible, since bluetooth networking is currently not supported in the simulator.
check this for more detail..
http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/GameKit_Guide/GameKitConcepts/GameKitConcepts.html%23//apple_ref/doc/uid/TP40008304-CH100-SW1
I'm looking for a development board for WinCE, preferably with the following connectors:
VGA/DVI for screen
USB for kb/mouse
Ethernet (10Mbit is OK, 100 would be even better ;-) )
Storage (eg: SD/MMC/CF cards)
I'm looking for this, because I want to attend the Imagine Cup , Embedded Systems design. And I'm looking for a challenge, ofcourse ;-).
I found a board called HawkBoard (http://www.hawkboard.org), but I want to know if there are alternatives for about the same price (max $200 incl. shipping/customs/taxes). I need the BSP, ofcourse ;-).
Thanks!
Yvan
The eBox 2300/3300 is a low cost device that has been used for past Imagine Cup challenges. It's x86, comes with a BSP, is in an enclosure, is low cost ($195 or $255) and meets most of your needs.
Of course CE has forever shipped with a reference BSP for x86, so you can usually get just about any x86 device working, though most other devices tend to be pretty big physically.
There are also open source CE BSPs available for the BeagleBoard and GumStix.
The BeagleBoard is a good ARM system that costs $150. It has all the features you want, from the product page:
DVI-D for connecting digital computer monitors
Compatibility with a huge collection of USB peripherals including hubs, keyboards, mice, WiFi, Bluetooth, web cameras, and much more
MMC+/SD/SDIO interface for memory or wireless connectivity
S-Video out for connecting your NTSC or PAL television or wearable visor
Stereo audio in and out for a microphone and headphones or speakers
Power via typical USB chargers for cell phones from your laptop, from an automobile adapter, from batteries, or even from a solar backpack
I never tried Windows CE myself, but a google search suggests it's possible, and there's even a video on YouTube.
Another option is Gumstix, and there's a project on codeplex to help you get Windows CE on it.
I guess it also depends if you want to start something for fun or rather serious.
Check some of the big manufacturers homepages too, so you can see what specifications could
help the realisation of your ideas or set limits to them.
What helps for shure is if you choose a platform, that can be configured easily and its much more fun if you start with something that can work out of the box too.
Here an example, like you can find it on a lot of manufactureres homepages on the web.
http://www.toradex.com/En/Products/Colibri
Colibri modules feature state of the art technology, and aimed at low power systems that require high CPU performance. They are equipped withall the interfaces needed in a modern embedded device.
Colibri T20 features include:
· Dual Core ARM Cortex A9 Processor
· 2 x 1.0GHz Processor Speed
· Full HD 1080p Video (Encode / Decode)
· Powerful 3D Rendering Performance
· True Dual Display
· Up to 12 Megapixel Camera Sensor Support
And if this is to much there are Colibri modules in the family which are in a lower price range with adapted specifications that might fit you needs better.
What I personally think is important, that you know that you can get good support and talk to the right people in person as well.
Give it a shot and good luck.
Regards
Any old PC that has a video adapter that is VESA compliant and a network adapter based on NE2000, realtek RTL8139 or 3COm 3Cx5 can be used as Windows CE target device using the CEPC BSP.
If you have an old 486 or more powerful PC lying unused somewhere in your garage, it's time to resurrect it! :)
I need to develop mobile application, so I decided to develop the application on J2ME.
This application must be support for Blackberry mobile, in this application we are using google maps, so can I use the J2ME software and if I develop the application in j2me how many types of mobile can support my application?
If any better software is there for supporting different mobile please suggest me.
I already developed the application in Android, this software supports few mobile, so I need to develop the application which mobiles are not supporting the android.
J2ME used to be the most widely deployed runtime on mobile phones wordwide (it may still be, depending on when you read this and the amount of Android phones sold by then).
These days, there are many phones that don't support it:
- closed phones (they don't let you install any application)
- Android
- iPhone
- BlackBerry 10
- The Palm WebOS phones
- I don't know whether the Samsung Bada phones support J2ME
- I expect that most of the mobile linux handsets (Maemo, Meego, Limo, Sailfish...) don't include J2ME by default. They tend to prefer a port of the Android runtime
- ...
The problem in developing an application that needs to support many handset models in many different countries is J2ME's curse: the dreaded fragmentation.
J2ME itself usually means the JSR-118 specification, along with a whole bunch of other optional APIs specified in JSR-75, JSR-82, JSR-120, JSR-135, JSR-139, JSR-172, JSR-177, JSR-179, JSR-180, JSR-184, JSR-185, JSR-205, JSR-211, JSR-226, JSR-229, JSR-234, JSR-238, JSR-239, JSR-248, JSR-256. You can see them all here.
These specifications have been interpreted differently by different companies implementing J2ME and they are often too generic to ensure the same piece of code to work identically on different phones.
Different mobile network operators also impose different requirements that sometime force mobile phone manufacturers to change the way their implementation of J2ME works based on who subsidizes the handset.
Operators can also modify data that goes through their mobile network.