The only below languages are supported by UITextChecker for autocorrection words or misspelled words.
“en_GB”,
“es_ES”,
“fr_FR”,
“it_IT”,
“pt_BR”,
“pt_PT”,
“nl_NL”,
“de_DE”,
“en_CA”,
“ru_RU”,
“en_US”,
“en_AU”,
“sv_SE”,
“da_DK”
In Iphone Programming Bad_Excess Does not throw any Exception
In my case :
Problem:-
NSString *str;
if( [ str isEqualToString @"NE" ] )<= this will generate bad excess beacuse
{
}
Sol n:-
NSString *str=@" "; <= sol n NSString Can not be null while we compare it
if( [ str isEqualToString @"NE" ] )
{
}
we can get details of Bad_Excess by using NSZombie Enable
For symbolicating crash log, It just require two files and simple steps.
Required :
1. The app file that you submitted for testing or to iTune Store.
2. .dSYM file which is generated at the time of above app file.
Follow steps.
1. Put the app file and .dSYM file in one new folder.
2. Put the attached file (symbolicatecrash) in folder /usr/local/bin/
3. Launch Terminal, execute command
symbolicatecrash myapp.app myapp.dSYM (where myapp is file name of app and .dSYM file)
It will symbolicate all symbols in your crash file.
Happy Coding..
–HS
UIProgressHUD is the private class of Apple API, So don’t extend this class or use it, otherwise after uploading binary on App Store, it will show “Invalid Binary”.
Mail from Apple
—————-
Non-public API usage:
The app contains or inherits from non-public classes in <>: UIProgressHUD
Good Luck iOS develoeprs
DO YOU VOTE FOR ANDROID OR IPHONE?
WHAT DO YOU THINK, WHO WILL WIN IN 2012?
1.What is JasperReports:
JasperReports is a powerful open source reporting tool that has the ability to deliver rich content onto the screen, to the printer or into HTML, XLS, PDF, CSV and XML files. It is entirely written in Java and can be used in a variety of Java enabled applications to generate dynamic content.
Its main purpose is to help creating page oriented, ready to print documents in a simple and flexible manner.
JasperReports organizes data retrieved from a relational database through JDBC according to the report design defined in an XML file. In order to fill a report with data, the report design must be compiled first.
The compilation of the XML file representing the report design is performed by the compileReport() method exposed by the dori.jasper.engine.JasperManager class.
Through compilation, the report design is loaded into a report design object that is then serialized and stored on disk (dori.jasper.engine.JasperReport). This serialized object is then used when the application wants to fill the specified report design with data. In fact, the compilation of a report design implies the compilation of all Java expressions defined in the XML file representing the report design. Various verifications are made at compilation time, to check the report design consistency. The result is a ready to fill report design that will be then used to generate documents on different sets of data.
In order to fill a report design, one can use the fillReportXXX() methods exposed by the dori.jasper.engine.JasperManager class. Those methods receive as a parameter the report design object, or a file representing the specified report design object, in a serialized form, and also a JDBC connection to the database from where to retrieve the data to fill the report.
The result is an object that represents the ready to print document (dori.jasper.engine.JasperPrint) and can be stored onto the disk, in a serialized form, for later use, or can be delivered to the printer, to the screen or can be transformed into a HTML, XLS, PDF, CSV or XML document.
JasperReports’ reports are defined in XML files, which by convention have an extension of jrxml. A typical jrxml file contains the following elements:
• jasperReport – the root element.
• title – its contents are printed only once at the beginning of the report
• pageHeader – its contents are printed at the beginning of every page in the report.
• detail – contains the body of the report.
• pageFooter – its contents are printed at the bottom of every page in the report.
• band – defines a report section, all of the above elements contain a band element as its only child element.
All of the elements are optional, except for the root jasperReport element.
2.Jasper available Plugins:
JasperAssistant is a visual report designer for JasperReports, a popular open-source reporting engine. It is built on top of the Eclipse’s plug-in architecture and its main goal is to help you create JasperReports report definition files through an intuitive graphical interface.
Benefits
• Design and layout your reports using an intuitive visual interface and avoid the need for XML editing of JasperReports templates.
• Take advantage of Eclipse IDE integration and effectively combine Java and JasperReports development.
• Efficiently locate and correct report problems using precise error indications.
• Preview your reports instantly using live data from a JDBC database connection, an XML document, JavaBeans array or a custom data source.
• Export and preview your reports in PDF, Excel, HTML, CSV and XML formats.
Here is some very good description of what you have to take into account to compute the (shallow) size of an java object.
The general rules for computing the size of an object on the SUN/SAP VM are :
32 bit
Arrays of boolean, byte, char, short, int: 2 * 4 (Object header) + 4 (length-field) +
sizeof(primitiveType) * length -> align result up to a multiple of 8
Arrays of objects: 2 * 4 (Object header) + 4 (length-field) +
4 * length -> align result up to a multiple of 8
Arrays of longs and doubles: 2 * 4 (Object header) + 4 (length-field) +
4 (dead space due to alignment restrictions) + 8 * length
java.lang.Object: 2 * 4 (Object header)
other objects: sizeofSuperClass + 8 * nrOfLongAndDoubleFields + 4 * nrOfIntFloatAndObjectFields +
2 * nrOfShortAndCharFields + 1 * nrOfByteAndBooleanFields -> align result up to a multiple of 8
64 bit
Arrays of boolean, byte, char, short, int: 2 * 8 (Object header) + 4 (length-field) +
sizeof(primitiveType) * length -> align result up to a multiple of 8
Arrays of objects: 2 * 8 (Object header) + 4 (length-field) +
4 (dead space due to alignment restrictions) + 8 * length
Arrays of longs and doubles: 2 * 8 (Object header) + 4 (length-field) +
4 (dead space due to alignment restrictions) + 8 * length
java.lang.Object: 2 * 8 (Object header)
other objects: sizeofSuperClass + 8 * nrOfLongDoubleAndObjectFields + 4 +
nrOfntAndFloatFields + 2 * nrOfShortAndCharFields + 1 * nrOfByteAndBooleanFields -> align result up to a multiple of 8
Note that an object might have unused space due to alignment at every inheritance level (e.g. imagine a class A with just a byte field and class B has A as it’s superclass and declares a byte field itself -> 14 bytes ‘wasted on 64 bit system).
In practice 64 bit needs 30 to 50% more memory due to references being twice as large.
Probably most of the Java users is aware that String object is more complex than just an array of char. To make the usage of strings in Java more robust additional measures were taken – for instance the String pool was created to save memory by reusing the same String objects instead of allocating new ones. Another optimization that I want to talk about today is adding the offset and count fields to the String object instances.
Why those fields were added? Their purpose is to help to reuse already allocated structures when using some of the string functionalities – like calculating substrings of a given string. The concept is that instead of creating an new char array for a substring we could just ‘reuse’ the old one. To be exact this is what String.substring() method does: instead of copying an char array for the returned object it creates a new String reusing char[] of the old one. Only the values of offset and count fields (which indicate the beginning and the length of a new string) are changed. Because the substring operation is quite often used this mechanism helps to save a lot of memory. It is important to add that this can work only because String objects are immutable. See the following snippet:
——————————————————————
public static void sendEmail(String emailUrl) {
String email = emailUrl.substring(7); // ‘mailto:’ prefix has 7 letters
String userName = email.substring(0, email.indexOf(”@”));
String domainName = email.substring(email.indexOf(”@”));
}
public static void main(String[] args) {
sendEmail(”mailto:user_name@domain_name.com”);
}
——————————————————————
Thanks to the way substring() is implemented when we extract the email, userName and domainName three new String objects are created, but the char array is not copied. All new string variables reuse the character array from emailUrl. Thanks to that reuse for really long urls we can save approximately 2/3 of memory we would use otherwise. Great, right?
Ok… now the dark side of that optimization! Check out this snippet:
——————————————————————
public final static String START_TAG = ““;
public static String getPageTitle(String pageUrl) {
// retrieve the HTML with a helper function:
String htmlPage = getPageContent(pageUrl);
// parse the page content to get the title
int start = htmlPage.indexOf(START_TAG);
start = start + START_TAG.length();
int end = htmlPage.indexOf(END_TAG);
String title = htmlPage.substring(start, end);
return title;
}
——————————————————————
In here we are extracting from the HTML page its title – can you see the problem with this code? Looks simple and correct, right?
Now, try to imagine that the htmlPage String is huge – more than 100.000 characters, but the title of this page has only 50 characters. Because of the optimization mentioned above the returned object will reuse the char array of the htmlPage instead of creating a new one… and this means that instead of returning a small string object you get back a huge String with 100.000 characters array!! If your code will invoke getPageTitle() method many times you may find out that you have stored only a thousand titles and already you are out of memory!! Scary, right?
Of course there is an easy solution for that – instead of returning the title in line 13, you can return new String(title). The String(String) constructor is always doing a subcopy of the underlying char array, so the created title will actually have only 50 characters. Now we are safe:)
So what is the lesson here? Always use new String(String)? No… In general the String optimizations are really helpful and it is worth to take advantage of them. You just have to be careful with what you are doing and be aware of what is going on ‘under the hood’ of your code.
Configuration Management(CM) is the discipline that ensures that the state of the software at any given time is known and reconstructable. CM comprises three basic elements: configuration identification (CID), configuration control (CC), and configuration accounting (CA). While each element may be invoked without the others, CM is incomplete in the absence of any of them.
CID provides a method for specifically and uniquely identifying each instance (e.g., release, version) of a given software product or set of products. By using a standard naming convention that allows for the identification of every instance of the product, each new draft of a document, each new compilation of a unit, or each new build can be specifically identified.
CC is the element that ensures that each change to an instance of the product is known, authorized, and documented. CC includes the activities of the change control board (CCB), which reviews and authorizes changes to the documents and code as increasingly formal control is placed on the developing software system. The software library may also be included as a function of CC.
CA serves to keep track of the status of each instance of the product. This becomes increasingly important as units and modules are integrated into subsystems and systems. It is obvious that the specific parts of a given system must be known so the system itself can be known. CA also assigns and tracks the status of each baseline of the requirements, test, design, code, and so on, as the software effort proceeds. Another growing requirement for CA is the case of a basic product that is adapted for use in multiple installations, each with slight variations in the total requirements set.
A Configuration Item (CI ) is any product of the software development process that is to be configuration managed. Each CI must have a unique identifier to differentiate it from all other software development products and other instances of the item itself.
Ultimate access to the Software Life Cycle(SLC) products, so that changes can be made, is through the software library, which is the repository of the official, approved issues of all documents and code. Changes to the products of the software development process come from two main sources: defect correction and enhancements. Without an effective change processing mechanism, the software can easily become unidentifiable and unmanageable.
Coordination of changes and their intercomponent effects is the task of the CCB. The CCB is responsible for determining that all effects of the proposed change have been anticipated and reconciled. Especially important is the control that the CCB exercises over the creation of new instances or versions of the various software system products. Once CM has been imposed on the project, it is the CCB that has the authority to approve changes and permit the updating of the various issues of the products. It is the responsibility of the software quality practitioner to monitor the functioning of the CCBs
Requirements reviews are intended to show that the problem to be solved is completely spelled out. Informal reviews are held during the preparation of the document. A formal review is appropriate prior to delivery of the document.
Requirements statements must meet a series of criteria if they are to be considered adequate to be used as the basis of the design of the system. Included in these criteria are the following:
• Necessity;
• Feasibility;
• Traceability;
• Absence of ambiguity;
• Correctness;
• Completeness;
• Clarity;
• Measurability;
• Testability.
A requirement is sometimes included simply because it seems like a good idea; it may add nothing useful to the overall system. The requirements review will assess the necessity of each requirement. In conjunction with the necessity of the requirement is the feasibility of that requirement. A requirement may be thought to be necessary, but if it is not achievable, some other approach will have to be taken or some other method found to address the requirement. The necessity of a requirement is most often demonstrated by its traceability back to the business problem or business need that initiated it.
Every requirement must be unambiguous. That is, every requirement should be written in such a way that the designer or tester need not try to interpret or guess what the writer meant. Terms like usually, sometimes, and under normal circumstances leave the door open to interpretation of what to do under unusual or abnormal circumstances. Failing to describe behavior in all possible cases leads to guessing on the part of readers, and Murphy’s Law suggests that the guess will be wrong a good portion of the time.
Completeness, correctness, and clarity are all criteria that address the way a given requirement is stated. A good requirement statement will present the requirement completely; that is, it will present all aspects of the requirement. A statement that correctly and completely states the requirement but cannot be understood by the designer is as useless as no statement at all. The language of the requirements should be simple, straightforward, and use no jargon. That also means that somewhere in the requirements document the terms and acronyms used are clearly defined.
Measurability and testability also go together. Every requirement will ultimately have to be demonstrated before the software can be considered complete. Requirements that have no definite measure or attribute that can be shown as present or absent cannot not be specifically tested.
The formal SRR is held at the end of the requirements phase. It is a demonstration that the requirements document is complete and meets the criteria previously stated. It also creates the first baseline for the software system. This is the approved basis for the commencement of the design efforts. All design components will be tracked back to this baseline for assurance that all requirements are addressed and that nothing not in the requirements appears in the design.
The purpose of the requirements review, then, is to examine the statements of the requirements and determine if they adhere to the criteria for requirements. For the software quality practitioner, it may not be possible to determine the technical accuracy or correctness of the requirements, and this task will be delegated to those who have the specific technical expertise needed for this assessment. Software quality or its agent (perhaps an outside contractor or another group within the organization) will review the documents for the balance of the criteria.
Each nonconformance to a criterion will be recorded along with a suggested correction. These will be returned to the authors of the documents, and the correction of the nonconformances tracked. The software quality practitioner also reports the results of the review and the status of the corrective actions to management.
