Ok, folks, get ready. In a month or so, we will probably launch a separate SCMAD study forum, but for now, this is where we'll post exam-related information. Beta sign-ups and voucher requests will NOT begin until January (possibly even February), but here are the NOT QUITE BUT ALMOST FINAL objectives for the exam. They still may change slightly before the final exam is released, and possibly even before the beta, although only VERY slightly, if at all. No NEW objectives are likely to be added at this point, but some may slightly change or be consolidated. The beta is probably in late February, and the final exam in April or May. The reason that some people have already been given a voucher opportunity is because they were the people who participated in our objectives survey. The survey participants are given a voucher for the beta in response to their participation. The survey is what helps us determine how many questions for each objective should appear on the exam (important topics will have more questions written about them than will less important topics). Have fun -Kathy
P.S. PLEASE do not post these objectives on other sites, because they are not guaranteed to be final. This is for your help only, so if you want to post them, instead post a link to THIS thread. That way, if I need to update them, I can do it here.
Section 1 -- JTWI (JSR 185) and Overview / JTWI-compliant wireless apps 1.1 Identify the goals and characteristics of the JTWI specification (JSR 185), including the mandatory specifications, conditionally required specifications, and the minimum configuration. [JTWI spec 1.0 -- MIDP 2.0 (JSR-118), WMA 1.1 (JSR-120), MMAPI 1.1 (JSR-135), and CLDC 1.0/1.1 (JSR-30/JSR-139)] 1.2 Develop portable applications that are compatible with the requirements and restrictions an application programmer must adhere to, in order to ensure compatibility with a JTWI-compliant device, includes resource minimums (eg. standard-size application), clock resolution, the use of preferred MIME names, as applicable to CLDC 1.0/1.1, MIDP 2.0, WMA 1.1, and MMAPI 1.1) [JTWI-spec: example: programmer should not exceed 10 simultaneous threads, since a JTWI-compliant device is required to support only 10 as a minimum, or 40 milleseconds minimum clock resolution...] 1.3 Compare and constrast the relationship and differences between J2ME, CLDC, CDC, Personal Profile, Personal Basis Profile, MIDP, J2SE, JTWI, wireless technologies, and the purpose of configurations, profiles, and optional packages. [Not all of J2ME is in CLDC, not all of J2SE is in J2ME, CLDC does not encompass MIDP, etc. Note: we will not go into details about the APIs which are *not* part of JSR 185, but candidates should know that they exist.] 1.4 Develop and deploy JTWI-compliant applications including development, packaging, manifest, JAD files, testing, and OTA deployment. 1.5 Write code that effectively manages memory / garbage collection. ========================================== Section 2 -- CLDC (1.0 / 1.1) [security covered in separate objective] 2.1 Identify correct and incorrect statements or examples about the requirements and scope of the CLDC specification, including the differences between 1.0 and 1.1. [CLDC addresses Java language, VM, core libs, io, security, networking, il8n, but NOT install, lifecycle, events, ui. CLDC 1.1 adds floating point, weak refs, thread names, min memory goes from 160 to 192 kb, recognize that reflection is not available but Class.forName() is... what the GCF depends on.]
2.2 Describe the ways in which a CLDC virtual machine does and does not ahere to the Java Language Specification (JLS) and the Java Virtual Machine specification. [Examples: error handling more limited, no user-defined class loaders, no thread groups or daemon threads, no finalization, no aysynchronous exceptions.]
2.3 Identify correct and incorrect statements or examples about CLDC classes including those derived from J2SE, and the CLDC-specific classes, including identifying which core J2EE classes are NOT included in CLDC, or have different behaviors (example: java.lang.String, io classes, etc.) [CLDC spec section 6]
2.4 Given the differences and limitations of exception/error handling with CLDC devices, handle exceptions correctly. [CLDC spec] ========================================= Section 3 -- Security (both CLDC and MIDP) 3.1 Explain CLDC requirements for class file verification (including both the standard JVM approach and the alternative off-device preverification approach, class file format, and class loading). [CLDC section 5.2, 5.3 -- talks about lookup order also. Emphasize pre-verification.]
3.2 Given a set of requirements, design and build applications given CLDC-specified application-level security, including the sandbox model.
[CLDC section 3.4.2, app programmer can't modify or bypass system classes, native functions not accesible except those in CLDC, MIDP, or a vendor-specific class, verification guaranteed, cannot modifiy class file lookup order, app can load application classes from ONLY its own JAR file.]
3.3 Identify correct and incorrect statements or examples about untrusted MIDlet suites. [MIDP 2.0 spec, Chapter 3, a MIDlet suite from a JAR file that cannot be trusted by the device. Include questions on the access that must be allowed implicitly within the 'untrusted domain' -- RMS APIs, MIDlet lifecycle APIs, UI APIs, Game APIs, multimedia APIs for sound, and with EXPLICIT confirmation from user: http and https.]
3.4 Explain trusted MIDlet suite security authorization and permissions, including the process for MIDlet suite signing. [MIDP 2.0 spec, Chapter 3]
3.5 Explain requirements and process of using X.509 PKI authentication for MIDlet suites. [MIDP 2.0 spec, chapter 4]
3.6 Given a scenario or example, discuss issues and requirements regarding the JSR 185 (JTWI) security policy for GSM/UMTS compliant devices. [JTWI spec, chapter 7, extends the base MIDlet suite security framework and defines required trust model for GSM/UMTS devices, capabilities of MIDlets based on permissions defined by MIDP 2.0, definition of user permission interaction modes, guidelines for user prompts and notifications.]
========================================= Section 4 -- Networking 4.1 Write code using the Generic Connection framework specified by CLDC, recognizing its characteristics, use, classes, and interfaces. This may include indentification of the class hierarchy and relationships of the Generic Connection framework. [CLDC 1.1 spec, section 6.3 (CLDC-supported classes)]
4.2 Write code for MIDP 2.0 networking, including the PushRegistry, and issues and limitations related to HTTP, HTTPS, and TCP/IP sockets and Datagrams, recognizing which connections are required and which are optional, as well as comparing the issues related to TCP/IP and UDP Datagrams.
[MIDP 2.0 - javax.microedition.io section. Can include questions on limitations of HTTPConnection in GCF, like cookies, URL rewriting, HTTP authentication, etc.]
4.3 Write code using the MIDP 2.0 classes in the javax.microedition.io package, including code that correctly opens, closes, and uses a network connection, using the implications of network blocking operations, scheme, connection number limitations, and character encoding. [MIDP 2.0 spec -- may include questions on using worker threads for network operations]
4.4 Given a problem scenario, troubleshoot portability-related networking issues for MIDP 2.0. [MIDP 2.0 spec] [Questions for chapter 4 could cover some common HTTP issues like an understanding of request methods (GET/POST) and how they differ, and why/where we may choose one over the other, sending and receiving header info, etc.]
Section 5 -- Application Model /Delivery / Lifecycle / Provisioning 5.1 Explain the specification guarantees for: browsing for MIDlet suites, transferring MIDlet suites, using HTTP, push registries, basic authentication, installing and updating MIDlet suites, invoking MIDlet suites, and deleting MIDlet suites. [MIDP spec 17-27] 5.2 Identify correct and incorrect statements or examples about the MIDP application model, including: the MIDP execution environment, MIDlet suites, MIDlet suite packaging (including the manifest and the application descriptor), discovering available services on the device, discovering which version of MIDP/CLDC is on the device, 5.3 Develop applications that correctly reflect a MIDlet's application lifecycle, including: the purpose of the MIDlet class, communication with the application management software, platform request API, valid MIDlet states and transitions, and the behavior that should and should NOT be implemented within different lifecycle methods (including the constructor). [MIDP ch 12]
5.4 Deploy a MIDP 2.0 application with the correct use of JAD files and manifests. [There may be questions about the relationship between manifest and JAD. Some attributes are required in the manifest and protected by the digital signature, while some more configurable attributes are included in the JAD to allow flexible deployment. For attributes that are common in both files, they must agree.]
5.5 Given an installation failure, analyze the problem, including the implications of partial verification, and develop possible resolutions. 5.6 Given a set of requirements, develop applications that correctly implement MIDP 2.0 support for delayed or scheduled activities using timers and background threads. [MIDP ch 6] ============================================
Section 6 -- MIDP Persistent Storage 6.1 Develop code that correctly implements handling, sharing and removing RecordStores within MIDlet suites. 6.2 Develop code that correctly implements adding, retrieving, modifying, and deleting individual records in a RecordStore, and converting RecordStore record data to and from byte arrays, and that reflects performance implications. 6.3 Identify correct and incorrect statements or examples about filtering, comparing, event listening, and enumerating records in a RecordStore. [MIDP spec ch 14, book ch 11] ============================================ Section 7 -- Push Registry [previous objective 7, sound, has been folded into other objectives] 7.1 Explain MIDP 2.0 Push Registry benefits, and limitations, and describe its use in applications. [MIDP 2.0 spec] 7.2 Develop applications that correctly use MIDP 2.0 Push Registry including discovery, dynamic vs. static, and recognizing the types of connections that can and cannot be accepted.
[MIDP 2.0 can ask about: PushRegistry vs. MIDlet life-cycle, deregistration, discover connections with incoming data, alarm capabilities, required vs. optional connection types, PushRegistry-related exceptions, security implications...] ============================================
Section 8 -- MIDP UI API 8.1 Given a scenario, develop MIDP 2.0-compliant user interfaces, recognizing portability requirements and limitations (e.g. double-buffering not guaranteed), and performance issues (e.g. using inner classes, freeing memory buffers, etc.). [MIDP chapter 8, javax.microedition.lcdui package and javax.microedition.lcdui.game package]
8.2 Discuss the MIDP user interface high-level API including concurrency, portability, structure of the API, and interplay with the application manager. [MIDP 2.0 spec, chapter 8. Understand that Display.setCurrent() may not take effect immediately. It is up to the runtime when to refresh the screen -- could result in lost screens. That is particularly an issue when used in a multi-threaded environment.]
8.3 Explain the MIDP user interface low-level API including font support, the drawing model, repainting, and coordinate system. [MIDP 2.0 spec, chapter 8 (can include a question about the implications of portability and low-level API)]
8.4 Given a set of requirement, develop interactive MIDP 2.0 user interface code with proper event-handling (including both the highlevel and low-level APIs, and threading issues). 8.5 Identify correct and incorrect statements or examples about the classes (including the class hierarchy) within the javax.microedition.lcdui package. 8.6 Compare and contrast high-level and low-level APIs, including layout techniques. 8.7 Explain requirements, issues, class hierarchy, and relationships between items and screens. 8.8 Troubleshoot UI-related issues related to repainting and threads.
================================================ Section 9 -- MIDP Game API 9.1 Given a scenario, develop code using the MIDP Game API package to improve performance and reduce application size. 9.2 Compare and constrast the use of MIDP's GameCanvas class vs. the MIDP low-level Canvas. 9.3 Given a set of requirements, develop code using MIDP's LayerManager class. 9.4 Given a set of requirements, develop code using MIDP's Layer, Sprite and TiledLayer classes. [MIDP ch 9] ================================================ Section 10 -- Media using MIDP 2.0 and the Mobile Media API 1.1 (MMAPI) 10.1 Given a set of requirements, develop code using MMAPI's support for tone generation. 10.2 Given a set of requirements, develop code that correctly uses MIDP support for sound including audio playback, tone generation, media flow controls (start, stop, etc.), media type controls (volume, tone), and media capabilities using "Manager", "Player", and "Control" objects, recognizing the difference between required vs. optional features. 10.3 Develop code that correctly uses MMAPI support for playback and recording of media, including the use of the "DataSource", "Player", and "Manager" objects, support for audio and video capture and playback, system properties queries, recognizing the difference between required and optional features. 10.4 Identify correct and incorrect statements or examples about the media class hierarchies in both MIDP 2.0 and MMAPI 1.1. [MMAPI spec] ================================================ Section 11 -- Wireless Messaging API 1.1 (WMA) 11.1 Describe the WMA's basic support for sending and receiving messages, and the Generic Connection Framework. 11.2 Explain the WMA's support for SMS and Cell Broadcast capabilities. 11.3 Identify correct and incorrect statements or examples about WMA including the WMA addressing scheme, client vs. server connections, WMA-related exceptions, WMA-related security issues, message size limitation, message creation, sending, synchronous vs. asynchronous message receipt, and the relationship between WMA and Push Registry.
Originally posted by Quentin Ng: Will there be any other new or upgrade exam upcoming in 2004?
I think they rather like surprising us, so I wouldn't be surprised if we don't get a real answer. I, though, am looking forward to the ever-broadening of the exams. It's nice to see the tests touching on all corners of the Java world.
Theodore Jonathan Casser
SCJP/SCSNI/SCBCD/SCWCD/SCDJWS/SCMAD/SCEA/MCTS/MCPD... and so many more letters than you can shake a stick at!
finally a certification on J2ME is being released, and the certifications for all Java technologies will be complete, I will be interested in getting this cert by learning this very high demanding technology even though i never used j2me b4 and is unfamiliar with it.
BEA 8.1 Certified Administrator, IBM Certified Solution Developer For XML 1.1 and Related Technologies, SCJP, SCWCD, SCBCD, SCDJWS, SCJD, SCEA,
Oracle Certified Master Java EE 5 Enterprise Architect
Joined: May 23, 2003
where can I obtain the book or the specification (like EJB2.0 for SCBCD) for this certification exam?
but isnt there a specification just right for the SCMAD exam? like the EJB2.0 specification is for SCBCD,because i passed SCBCD just by studying EJB2.0 spec. I am wondering if there is another J2ME specification from Sun Microsystems thats for SCMAD. i dont put logos on my business card. our company make the business card for us.
Joined: Jan 23, 2002
but isnt there a specification just right for the SCMAD exam?
Well, like it or not, the J2ME specifications covered by the certification are distributed over a number of JSRs so you can't just read one spec and be done with it. I trust that there will be an all-in-one study guide for this exam too, soon...
i dont put logos on my business card. our company make the business card for us.
Howdy all! Well, we just survived the development of the exam. Michael Yuan was there *in spirit*, as he lead the development of the original objectives and influenced the nature of many of the questions -- keeping them heavily focused on performance and portability issues whenever possible. There are no questions on anything that is device/vendor-specific. The exam is based on five specifications: [JTWI spec 1.0 -- MIDP 2.0 (JSR-118), WMA 1.1 (JSR-120), MMAPI 1.1 (JSR-135), and CLDC 1.0/1.1 (JSR-30/JSR-139)] What I recommend studying is CLDC and MIDP 2.0 specs. By far, those are the two that will answer most of the questions -- if you look on the objectives, you'll have a really good idea about the spec that is driving that questions from that objective. The questions on WMA are very straightforward, as are the questions on MMAPI. But almost everything else in the exam centers around MIDP 2.0 and/or CLDC 1.1. The questions are in a format that is similar to the new (not yet released) SCWCD exam: a *lot* of code from which you have to decide what the impact of that code is... is it *guaranteed* portable? Is it a good strategy for memory management? Will it perform better than this other alternative? Is it even LEGAL? Things like that. There are also a lot of drag and drop questions, and questions with pictures. Imagine, say, a picture of three sprites, showing the collision rectangles around each. You then have to look at the code and determine whether the sprites are in collision, and the impact on performance. So you'd need to recognize the differences between pixel-level and boundary-level detection. Another picture shows an interface (all pictures are from the emulated phones in the WTK, by the way) and you have to figure out what can be determined based on that picture. For example, if you see the EXIT command mapped to wherever the EXIT button goes, and then you see other commands in a MENU, does it mean that the EXIT *must* have had a higher priority than the menu commands? (No -- the code might show that the EXIT has the lowest priority of all, but it still may be mapped to the EXIT button by the device, while the *screen* commands with a higher priority still go into the menu). Things like that... Yes, we will have *many* examples to show you before the beta exam happens! It is NOT time to request vouchers for the beta. But don't worry, we will announce all that. There are a couple of potentially interesting and different things that may happen with the exam, and we should have all the info within a week or two. At that time, we will probably spin off a separate forum just for this exam. So if you're interested, I suggest you download the CLDC 1.1 spec and the MIDP 2.0 spec and pay close attention to what is guaranteed by each. You *are* tested on some aspects of the MIDP 2.0 API (look at the objectives!) although we tried very hard to avoid trivia questions. For example, we wouldn't test to see if you knew the order in which arguments to a method must be passed. But in a few key cases, you MIGHT be asked what certain arguments really *mean* in terms of behavior. You can test the characteristics of these specs using the new version of the WTK. Cheers and have fun! -Kathy Oh yeah, I forgot to mention -- Michael's book, although covering primarily areas which are not on the exam, was still a big favorite of the developers during the exam creation workshop. Particularly the stuff on wireless messaging! He explained things in a way that actually *make sense* where the spec is more confusing to read. And his examples on reading and writing record stores were extremely clear and helpful. Stay tuned...
Was there any thought to including the CDC on the exam? I think it's unfortunate that technologies such as Personal Java and Personal Profile have been neglected for so long. I would still like to see the prevalence of Java on high end devices someday. Regards, Drew Lane
Originally posted by Kathy Sierra: Well, we just survived the development of the exam. Michael Yuan was there *in spirit*, as he lead the development of the original objectives and influenced the nature of many of the questions -- keeping them heavily focused on performance and portability issues whenever possible. There are no questions on anything that is device/vendor-specific.
Congratulations! I wish all ranchers would find the exam helpful in launching their J2ME careers!
Oh yeah, I forgot to mention -- Michael's book, although covering primarily areas which are not on the exam, was still a big favorite of the developers during the exam creation workshop. Particularly the stuff on wireless messaging! He explained things in a way that actually *make sense* where the spec is more confusing to read. And his examples on reading and writing record stores were extremely clear and helpful.
Originally posted by Mark Spritzler: No books have been released for this new exam. Although when Beta time comes around I am sure that Kathy and Bert will have some sample chapters of an upcoming Head First book on this exam. Mark
Will there be any HF J2ME? I'm looking forward to it...
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com