So I'm looking to make my own not so smart "smart" watch Bluetooth device. From what I've found online, I will need some sort of "brain", a thing capable of using BLE, and since I want a display, also an led screen. I need to display the time, and be notified when a call or text is received.
My question comes down to these 3 points-
What should I use/buy for the brain? I'm assuming some sort or variant of a little cpu? I'm also going to need the Bluetooth side of it, but I'm unsure of what I would need that is capable of giving BLE to my device.
Is it possible to make the software side out of this in Java? It is the only language I know extensively, but I'm willing to learn any of it is needed.
Is there anything special I would have to do to pair it with an IPhone (such as make an app, code it a certain way, etc)
I'm sorry if at any point I'm too vague (I don't know enough not to be) or if I'm oblivious to any well known facts; this is my first time ever building an electronic device.
If you would like a smaller cheaper solution and you're somewhat accustomed to working with micro-controllers, I would say look at something like Arduino Micro plus a BLE shield or another brand micro-controller.
Arduino uses its own functional language that's fairly easy to learn coming from java and any other micro-controller would probably use C, if you decide to go that route. A micro-controller would most likely not support java, because the JVM is simply too large and has too much overhead for a tiny cpu.
The time should not be an issue to update via BLE. You can implement the calling and SMS via the ANCS protocol.
Here is a good example/tutorial for an arduino "smartwatch".
Related
I'm developing some standalone games but not online ones and really want to include in-app purchases for some items. I'm using Unity3D for Android platforms, so most of my code is written in C# and Java.
I know well there's no way to protect the code written in C# and Java from reverse engineering at all. Just in case, I searched for some in-app billing security guidelines but those didn't seem to be effective for standalone Android apps. If I was developing online games, then yes, I could try some ways to prevent from cracking, because the game can't be played without a server connection.
But that's not my case.
Even if I use super safe APIs in the world for server-side verification and revocability, there are always possibilities for crackers to decompile and modify the code to skip reaching the store or server and just return true.
Then they can pack it again as APK and play with no limitations. I also tried to write some important code in unmanaged C++ and use them in C#, but I quit it soon, because I thought it's also easy for crackers to break the connections between C++ and C#.
I've already said to myself there's no real solution for this. That's why I've never tried to put the in-app billing system yet.
But still wonder if there is anyway to make crackers harder to change the code for in-app billing, aside from real basic skills such as obfuscation.
I am a new one in Java programming i want to know how overall concept of Socket and Server-Client work and how modification in one's system tends to the modification in other's system, As a starter i am making TicTacToe 2 player in java, i had made TicTacToe for Single Player but want some help to make it in multiplayer.I had gone through many question (on this site) before but they only solve some kind of problem but i want a full knowledge that how this all stuff works.
Can any one please tell me that how Server and Client do the message passing in Java ??
I want to ask where to write my Game Code so that it get loaded on both the devices and when user make a turn it get displayed into another user's device also...
There are many different answers/solutions for the use-case you described.
But never never develop network communication on a low-level layer. There are different solutions (api) to put the data(messages) into higher layers(f.e. HTTP). That enables you to turn your software very easy into a multithreaded and/or multisession-app.
I would prefer in your simple application an implementation with jersey and grizzly. You'll find lot of how-to's with google ("web services jersey grizzly") and here in stackoverflow of course. ;)
I have a microcontroller that when an event, I want it to send an email. I know how to use email in Java, but how can I put that Java code in the midst of the C code of the microcontroller?
#include <avr/io.h>
#include <util/delay.h>
int main(void)
{
DDRB |= 1 << PINB0; // = 0b00000001
DDRB &= ~(1 << PINB1);
PORTB |= 1 << PINB1;
DDRB |= 1 << PINB2;
while(1)
{
PORTB ^= 1 << PINB0;
if(bit_is_clear(PINB, 1)){
PORTB &= ~(1 << PINB2);
_delay_ms(100); //SLOW
}
else{
_delay_ms(10); //FAST
/////I want the Java code in here/////
PORTB ^= 1 << PINB2;
}
}
}
EDIT
I'm using an Atmel Atmega8A microcontroller. I'm making a simple alarm system, that if the wire at pin B1 is disconnected, I want to get an email or text notification.
And I'm just a high schooler novice so please don't go over my head too much...
Oh and if someone could water down multithreading in C for me that would be nice. I come from a Java background since that's what they teach in high school.
Well your "question" is to embed Java to your AVR... but what you actually want to is send email. There are some implementations to run Java bytecode (or at least I think so), but I believe none of these will be able to send email.
You need to understand that an AVR is very limited in functionality. To send email, your setup will need to connect to the Internet, with TCP/IP. Something so complicated that cannot be accomplished with the ATmega8A itself. It may be possible to find a hardware which you can communicate via UART in order to send email, or you can simply hook it to a PC and run a application to listen to the COM port and send email, or... anyway you need extra hardware.
You may want to look into other microcontrollers instead. I believe there are some with networking support, but they will probably be very expensive. Or, you can just use a Raspberry Pi instead.
Java and C are very, very different langauges.
You'll need to find a compiler for your microcontroller that supports Java.
However, if your controller can get C compiled via GCC, then use of GCJ may work with certain memory constraints on the target platform. You'll need to generate an object file of the correct architecture, and link it using microcontroller-compatible gcc.
This is not worth its time. I recommend implementing it in C instead.
Besides, opening files and sockets may not occur since a microcontroller usually does not provide any kernel routines beyond certain aspects of hardware access. libc will also likely be absent or minimal.
You might also not have networking hardware. If you can tell us which microcontroller, we could help.
A more direct answer to the question was given already by Alvin Wong, but I feel your question is so out of focus that it might be good to help you refocus it.
You should start understanding what is really happening when you send a mail from a Java program, then understand what part of it can actually be done by your microcontroller, and how.
So, what happens when you run your mail-sending Java program?
You wrote the program in the Java language, which got compiled into Java bytecode, which gets interpreted by the Java Virtual Machine, which will call some library provided by the Java runtime,
which will (probably indirectly) start a "network communication", which will take advantage of the Operating System network facilities, ...
which will use the network hardware,
to communicate with a mail server using some mail protocol, and send it some specific sequence of bytes that will make it understand that a mail message is being sent to someone.
The (1) part is mediated by all the layers of the Java platform. (Remember: Java is much more than a language).
The (2) is a layer (or couple of them) under the Java platform, and includes all of your Operative System (Windows, Linux, Mac OS X, whatever).
The (3) is a layer comprised of your hardware, and that includes other sublayers like the firmware in your network card, which is still more software that might manage things like the Ethernet / Wifi protocols' details.
The (4) layer is rather bits and bytes being flipped on and off in some communication channel (Ethernet, WiFi, whatever).
Now, what part of it can be done with your microcontroller?
A microcontroller sits in the lower part of (3). In your case, the Atmega doesn't even have any network hardware support, so ... I don't know how you are planning to connect to the network. Anyway, even if you had it, you are so close to (4) that it would rather be madness to try to go up to (1). (1) is say for elephants, (4) can be done by ants, and a microcontroller is about the size of a ladybug, to refer to Atmel's mascot :P.
So: stop thinking like an elephant. As it is you will have to work to get to your goal, but if you take the elephant's way, you'll be probably doing a ton of unneeded work - if it can be done at all, which I doubt.
(And if anyway I had to take the elephant's way, namely use Java in an AVR, I would start by looking at GCJ or LLVM options. I know that some work was done to port minimalist JVMs to 8 bit microcontrollers more than a decade ago, but no idea how that evolved)
Like others said, sending an e-mail this way is really really far from your micro (I assume you primarily want to send the mail, not to run a Java VM in there). To get the mail going, you need to connect to the Internet using TCP/IP, then using for example the SMTP protocol, you may be able to accomplish this.
The problematic part is connecting to the Internet. For this you need to get your device on a "suitable wire", which is typically Ethernet, but radio based solutions may also exist. Then you would have to implement everything necessary to communicate on that wire (the whole network stack until TCP/IP). This can not reasonably be done all yourself. One way is to use a micro which has some built in Ethernet connectivity and use for example lwip or Contiki depending on your preferences to do the magic. The other way is using extra hardware which does the thing for you such as this Moxa product, but you may not be able to implement SMTP over this.
Then you will "only" need to implement a suitable SMTP (Simple Mail Transfer Protocol) layer to properly send your mail (one or another of the solutions I presented above may already have this for you).
Your microcontroller will need to support the JDK or Java ME (maybe Sun SPOT). http://www.inonit.com/cygwin/jni/invocationApi/c.html has an example of using the JNI to start the JVM and invoke your class.
Microcontrollers very very typically are developed in the C environment since in a microcontroller there are limited resources in terms of hardware power. C is used since it allows the most flexibility and allows fine tuning since in the microcontroller environment real-time computer is very essential. That is not to say though, there is java used in the microcontroller world. Very convoluted though, android runs on some java which in the lowest end possible uses a ARM processor (its up to you to decide if you really want to call that a microcontroller). So all in all, yeah I would recommend that you learn C. If you really want to go the java way, I have not personally run into a lot of resources that allows you to use java on a AVR microcontroller. It might be possible, but expect a hit on performance.
If you have no experience in microcontrollers, I would recommend looking into Arduino (arduino.cc).
Best of luck!
I'm developing a distributed application, and I need to connect a client Java based to a server C++ based. Both of them will need to send information to each other, but I need them to be able to do things while waiting for the information, and they don't know when they are gonna get new information, or send information.
How can I achieve this? Now I'm trying to implement a basic communication with Sockets, but I don't really get to communicate them. I have read that using sockets + threads is usually a good approach for client-server apps.
Could you please recommend me some web or book to read about this, or send me some example code to learn?
Do you think that i should use other approach, better than sockets? maybe a higher level library (i would need it for c++ and java) or a totally different way?
EDIT:
I will add some extra information.
What I would love to achieve is the following:
My C++ program has a main loop, where I would like to have a call like GetUpdatedDataFromRemoteDevice() where I read the new values of some numerical variables that previously got updated from the net (the socket, for example).
Eventually, the C++ program will need to send a message to the remote device, to tell him to send other kind of data, and after that, keep getting the updated values.
From the Java program (remote device) the application running is an interactive touchable screen, that cant get blocked by the network transmissions, because it must keep working for the user, so all the networking should be done in a separated thread.
That thread, should connect to the server, and when a button is pushed, start to send the data (4 changing numerical values) in a loop until another event happens.
It would be nice also to be easily re-connectable to the server.
ICE is a modern and good library for distributed applications:
many languages as C++ and Java
many platforms
GNU GPL
good performance
easy to use
First, you define the messages you want to exchange between server and client.
Then, you implement the C++ and Java source code to handle these messages.
More info at http://zeroc.com/ice.html
Have fun ;-)
EDIT: I have to use ACE in some projects. I can tell ACE is very old, maybe mature, but uses outdated C++ coding rules :-(
Therefore ACE is not as easy to use as STL or BOOST. Moreover, ACE is not really efficient... I prefer ICE ;-)
I don't know what your application is but robust client server socket programming is pretty hairy task to do properly. Hardware byte order, String encoding, Network errors, retries, duplicate messages, acks etc.. require lots of good design and careful programming. You need to get it work well as single-threaded before even thinking using multiple threads.
Unless you need instant notifications from server to client I suggest that you use HTTP as protocol between client and server. Client can poll server occasionally for new messages.
Anyway the problem has been solved multiple times already.
http://activemq.apache.org/
http://www.rabbitmq.com/devtools.html
http://www.cs.wustl.edu/~schmidt/ACE-overview.html
I did something of this sort once. In my case it was easier to connect my C++ app to a local Java app using JNI and then have the two Java apps talk to each other.
I'm considering creating a screen reader for Android. My questions are as follows. One how much of the internals of Android are exposed through the Java API? I'm looking for things such as system wide notification when text is displayed, notification of a new application being launched, etc. I'd rather not have to modify the kernel source and only allow my app to run on a developer phone. Two, how much processor and memory are left over on the G1 assuming no applications running? Three assuming average use of applications on the phone how much processor and memory are left?
More info
I'm aware that applications should not be designed to work on a specific phone. I picked the G1 because it's the most popular phone currently running Android that I know of. I am looking for lower end system specs that my program would have to fit in, it may run great on a netbook with Android installed but use to much memory and processor to run on most Android handsets.
Update:
There are now two screen reader projects that use Android 1.6, they can be found at
http://google-opensource.blogspot.com/2009/10/talkback-open-source-screenreader-for.html
http://spiel.thewordnerd.info/
AFAIK, screen content (text, graphics) of other apps will for security reasons not be exposed in Android. Otherwise one could grab contact info or whatever personal information gets displayed and harvest that for malicious purposes. So developers currently cannot create an Android app that speaks the text displayed by another application, nor capture the screen. This situation is different from Microsoft Windows on the PC, where applications can do pretty much anything they like, such that the user must decide for himself whether the source of any given application is trusted.
Sadly, there is still no screen reader for Android on the market, so it would be great if you or someone else could create it, but it looks like only a direct arrangement with Google could provide the level of trust needed in view of the above security limitations. Since Google is actively working on improving the TTS and integrating it into Donut, it would seem a fairly simple extra step for them to create a basic Narrator-like (as in Windows) screen reader, or offer a similar touch-based accessibility solution as with VoiceOver on the iPhone 3G S.
Best regards,
Peter Meijer
The vOICe for Android
http://www.seeingwithsound.com/android.htm
(1) Depends on what you are looking for. You better check for yourself. I am not ware of any assistive technologies in place, but I wasn't looking for them either.
Regarding the two specific capabilities you asked for:
(a) Notifications are part of the API.
(b) I am not aware that you can be notified on applications being started.
(2/3) I don't the general amount of RAM that is available for apps, but I can give you an practical answer. Your app's process will be killed if it tries to grab more than 16MB.
I don't know the exact clock speed, but on the android-dev list it was mentioned that the G1 doesn't run at full speed. The rationale behind it is that among other things more speed would run down the battery much more quickly.
Just another practical matter regarding this question. If you want to discuss the constraints go to the android-dev list.