J2ME architecture - java-me

I was reading about the J2ME architecture where it was written that there are 3 layers
1) Configuration Layer: It has JVM and interacts with the OS
2) Profile layer: Minimum set of API's for small device
3) MIDP layer: Contains Java API's
The book is J2ME: The Complete Reference
QUESTIONS
1) Do every phone have an OS? If not what is the first layer doing in that case?
2) What is API's for small device?
3) MIDP is itself a profile which means it should be at second layer then how come it is at third layer?

Configurations and profiles are the main elements that comprise J2ME’s modular design. These two elements enable support for the plethora of devices that
J2ME supports.
A J2ME configuration defines a minimum Java platform for a family of devices.
Members of a given family all have similar requirements for memory and processing power.
A configuration is really a specification that identifies the systemlevel facilities available, such as a
set of Java language features,
the characteristics and features of the virtual machine present,
and the minimum Java libraries that are supported.
Software developers can expect a certain level of system support
to be available for a family of devices that uses a particular configuration.
A configuration also specifies a minimum set of features for a category of devices.
Device manufacturers implement profiles to provide a real platform for a family
of devices that have the capabilities that a given configuration specifies.
The other J2ME building block, the profile, specifies the application-level interface
for a particular class of devices. A profile implementation consists of a set of Java
class libraries that provide this application-level interface. Thus, a profile theoretically could specify all kinds of functionality and services.
This is not the intention of its creators, however. The creators of J2ME intend that
a profile should address the needs of a specific device category or vertical market
pertaining to that device category. The idea is not to place a plethora of unrelated
application level features in a profile. Rather, the main goal is to guarantee interoperability—which doesn’t necessarily imply compatibility between different manufacturers’ implementations—between all devices of the same category or vertical
market family to define a standard platform for Java application development.
For example, a profile might support a network communication facility for the
popular Short Message Service (SMS) standard widely used by mobile phones.
Because the SMS standard is a ubiquitous feature of mobile telephony, it makes
sense to define this service in a profile that targets mobile phones, rather than to
build it into a configuration.
A profile is implemented on top of a configuration, one step closer to the implementation of real-world applications.
Typically, a profile includes libraries that are
more specific to the characteristics of the category of devices they represent than
are the libraries that comprise configurations.
Applications are then built on top
of the configuration and profile; they can use only the class libraries provided by
these two lower-level specifications. Profiles can be built on top of one another. A
J2ME platform implementation, however, can contain only one configuration.
Figure 1.1 shows the conceptual layers that comprise the J2ME platform.
So far, these notions of configurations, profiles, and platform definitions is somewhat abstract. The next section gives you a more concrete description of the characteristics of actual environments.
Configurations and Profiles
A configuration specifies three basic elements:
• a set of Java programming language features
• a set of Java virtual machine features
• a set of supported Java libraries and application programming
interfaces (APIs)
Hope this will help you to understand J2ME Architecture.

Answers are as follows,
Yes, Every Phone has Operating System.
API's for small device(mobile phone) is depends on the oprating system loaded into the device.
MIDP is made up of Libraries, this is the reason it is on third layer as shown in the picture in above answer of Sajid.

Related

Custom Messages in Bluetooth Mesh

I am using Bluetooth Mesh technology for a project. The Bluetooth mesh works on flooding, and the message types are defined in the profile. However, I could not find whether I can include a custom payload in the messages to be delivered across the network. Is it possible to do this in Bluetooth Mesh? If yes, please suggest any resources that explain the functionality.
First of all you should visit the Bluetooth SIG. They own and publish all Bluetooth standards. They also maintain a comprehensive list of all specifications including those dealing with 'mesh':
https://www.bluetooth.com/specifications/specs/
And Nordic also provides extensive documentation with examples for its nRF5 SDK for Mesh:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fstruct_sdk%2Fstruct%2Fsdk_mesh_latest.html
Bluetooth Mesh is based on Model interaction. If your application does not fit into available (defined by SIG) models, you can create your own (Vendor) models. In that case you can define opcodes (which should not interfere with opcodes of other messages) and customize transferred data.
More information on how to create you own model, in case you are using Nordic SDKs you can find here: for nRF Connect SDK or for nRF Mesh SDK.

What considerations to make for selecting Bluetooth Chipsets for control of LED via PWM?

I am involved working on new hardware LED products where we are selecting a Bluetooth chipset to use in multiple products controlled by iOS and Android apps, for at minimum the next 3-4 years. Also I am not the developer, a third party will be contracted for this project.
As part of background research, I wanted to ask for feedback from Stack Overflow communities' experience with programming for Bluetooth, more specifically with custom firmware and GPIO PWM for LED?
What kind of challenges did you come across?
Are there any granular details or features to look out for with the hardware?
**Edit: based on first answer-
Requirements:
BLE 5
I do need OTA update capability
Chip size not big constraint, plastic enclosure can accommodate up to 1 inch/25mm or bit more easily.
Not high temp application
Single-chip solution, that will be programmed with our firmware, controlling 4x PWM Channels is ideal for our LED strips, avoiding separate MCU
Cost per unit (lowest average cost/unit)- important factor at volume, TBD
**Qualities I can not gauge well myself, being a designer and not an experienced programmer:
Ease of integration/support (lowest cost of development)
Quality of the chip manufacturer's software tools
Quality of the chips documentation
I have found some questions related with Raspberry Pi that seem generally helpful, but those questions don't help me with features or the support and documentation as related to BT SOCs.
**Edit: Yes I we are only considering BLE, and the NORDIC Semiconductor link I have included below are BLE and BT 5.
NORDIC chips are on my short list, they seem well supported and capable of 3x or 4x PWM channels for example nRF52832 Nordic nRF52832 Spec info. or the newer model RF5340. Does anyone have experience with them?
I really appreciate any answers regarding development considerations with Bluetooth.
I will edit & clarify if needed.
If you wish to support iOS Apps, a BLE device is necessary, BT classic requires a special apple license (for your product) to be able to connect with iOS Apps.
But other than that, your specifications dont really help to rule out ANY chip.
The first question that comes to mind is what other features do you
have already on your specification list that could be satisfied with
a common solution. I.e. if you also need WiFi, don't choose two
separate BLE/WiFi Chips, buy a chip that can do both (it's both
2.4GHz RF). If you need OTA updates for your firmware, choose a chip manufacturer with extensive and well documented tooling.
Consider special requirements:
Do you need a very small chip?
Does it need to be run at high temperatures (i.e. inside a light bulb)?
Do you need to run at ultra-low-power?
Does it need a high performance RF transceiver?
Decide whether you need a single-chip solution, that will be programmed with your firmware, or if your firmware will run on a dedicated microcontroller which is connected to the BLE chip.
Unless you have absolutely no special requirements to narrow down the selection, I'd base my decision along these criteria (not ordered):
Ease of integration (lowest cost of development)
Cost per unit (lowest average cost/unit)
Quality of the chip manufacturer's software tools
Quality of the chips documentation
GPIO-PWM Output should be possible with almost any programmable BLE chip.

What is Kinect + Linux being used for?

An article on Hackaday piqued my curiosity, and I see Kinect + Linux questions being asked here (mostly about configuration), so I'll venture this question:
It is clear to me that Kinect can be used together with Linux on a "regular pc" -- but I can't help wondering why, that is, what might you actually use this for?
I don't suppose people really like the human/computer interface presented in movies such as "Minority Report" -- surely, nobody is actually doing text editing, coding, or business data processing by "hand-waving". So besides just games & exercises, what are examples of actual, real-world, useful (ie. 'professional') applications of such a setup?
For instance, can it be used for 3D scanning of real-world objects to obtain digital models? What sort of accuracy would such a scan yield?
The Kinect can be used for a wide variety of useful applications. I'm not sure if you are asking specifically about Linux or if Windows ("regular PC") is acceptable, but I'll provide you with some examples that come to mind.
For Linux specifically, it is likely that applications on Linux are using the sensor's raw sensor data only, rather the skeletal tracking feature. Many Kinect applications are on Windows because Microsoft's Kinect SDK is available only on Windows, and it provides the best skeletal tracking accuracy to-date.
You are right that the Kinect is rarely used where a keyboard & mouse would be faster and more accurate, but note that it is potentially relevant for accessibility.
And yes, it can be used for 3D scanning of real-world objects. I'm not sure about the exact accuracy, but I think it is acceptable for many applications. The main benefits are its low cost and speed.
For examples of 3D scanning, check out:
KinectFusion, a Microsoft Research project
Occipital Structure sensor for 3D scanning. (This is not the Kinect sensor, but provides an example application for 3D scanning. The company has a Kinect-related history as well.)
Styku - 3D body scanning for clothes fitting
Aside from 3D scanning, here are some other examples of applications:
Atlas5D - at-home patient monitoring
GestSure - 'Minority Report' interface for surgical rooms
Jintronix - games, exercises, assessments for physical therapy
There are many depth sensors like the Kinect3D on the market. The latest notable application would be iPhone X's depth sensor and FaceID. Many companies in the space are working actively in FaceID now, which would also be useful on Linux. Check out Microsoft's Window Hello biometric facial ID system - see Microsoft's official website:
Manufacturing of the Kinect sensor and adapter has been discontinued,
but the Kinect technology continues to live on in products like the
HoloLens, Cortana voice assistant, the Windows Hello biometric facial
ID system, and a context-aware user interface.
Kinect has applications in the robotics community as well, though I don't know the specifics. I assume many in robotics community use Linux when working with the Kinect. The depth and color cameras can be used to provide vision and the microphone array for audio input.
Generally, the Kinect had a big impact when it was released not just because of its technology but also because of its low price point, even if it's not the most accurate for every application. As this technology improves, I hope many other applications will emerge and become mainstream.
EDIT: also, check out this Hacker News discussion: "Microsoft Has Stopped Manufacturing The Kinect"

where is the bluetooth 'dual-mode' definition?

I been reading through the Bluetooth 4.0 core specification. However, I cannot find anywhere which states the true definition of 'dual-mode'.
From other google results, it looks like 'dual-mode' means that a BT device that has this capability can communicate with a LE device and a BR/EDR device simultaneously. However, I cannot find any official bluetooth docs that states this feature.
The closest one that I can get is:
The Brand book uses the term “dual mode” device to refer to a design
(host and/or controller) that is qualified in compliance with the
Basic Rate and Low Energy Combined Core Configuration as defined in
the Bluetooth specification. It is also referred to in the Bluetooth
specification as a BR/EDR/LE design.
from here
Could someone point out the location where 'dual-mode' is defined?
There is some different logic.
The two most prevalent implementations of the specification are
Bluetooth Basic Rate/Enhanced Data Rate (BR/EDR), which was adopted as
version 2.0/2.1, and Bluetooth with low energy (LE), which was adopted
as version 4.0/4.1/4.2. Each implementation has different use cases
and each implementation uses a different chipset to meet essential
hardware requirements. Dual-mode chipsets are also available for
applications that include both use cases. https://www.bluetooth.com/specifications/bluetooth-core-specification
There is Bluetooth 2.x - BR/EDR spec and there is Bluetooth 4.x (now 5.0). They are individuals specification with different purposes and different tech implementation (different modulation, different DSP blocks, different modes of work, etc). Manufacturer like TI, STM and so on just implement both of theese specs on one chip (System on Chip) or in SiP (System in Package). And theese SoC and SiP named "dual-mode devices" and often BT 2.0 and BT 4.x work in theese SoCs (SiPs) simultaneously.

J2ME application how many mobile supports

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.

Resources