Friday, October 12, 2012

NSURL parsing

got something good, paste it here


- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
NSLog(@"%@", url);
    NSURL *url1 = [NSURL URLWithString:@"httpdd://www.mobileorchard.com"];
    NSLog(@"scheme: %@", [url scheme]);
    NSLog(@"host: %@", [url host]);
    NSLog(@"port: %@", [url port]);
    NSLog(@"path: %@", [url path]);
    NSLog(@"path components: %@", [url pathComponents]);
    NSLog(@"parameterString: %@", [url parameterString]);
    NSLog(@"query: %@", [url query]);
    return YES;
}

@interface NSString (ParseCategory)
- (NSMutableDictionary *)explodeToDictionaryInnerGlue:(NSString *)innerGlue outterGlue:(NSString *)outterGlue;
@end
@implementation NSString (ParseCategory)
- (NSMutableDictionary *)explodeToDictionaryInnerGlue:(NSString *)innerGlue outterGlue:(NSString *)outterGlue {
    // Explode based on outter glue
    NSArray *firstExplode = [self componentsSeparatedByString:outterGlue];
    NSArray *secondExplode;

    // Explode based on inner glue
    NSInteger count = [firstExplode count];
    NSMutableDictionary *returnDictionary = [NSMutableDictionary dictionaryWithCapacity:count];
    for (NSInteger i = 0; i < count; i++) {
        secondExplode = [(NSString *)[firstExplode objectAtIndex:i] componentsSeparatedByString:innerGlue];
        if ([secondExplode count] == 2) {
                [returnDictionary setObject:[secondExplode objectAtIndex:1] forKey:[secondExplode objectAtIndex:0]];
        }
    }

    return returnDictionary;
}
@end
It's called like this:
NSMutableDictionary *parsedQuery = [[myNSURL query] explodeToDictionaryInnerGlue:@"=" outterGlue=@"&"]
For parsing the path portion of the NSURL (ie @"/partA/partB/partC"), just call this:
NSArray *parsedPath = [[nyNSURL path] componentsSeperatedByString:@"/"];
Be aware that parsedPath[0] will be an empty string because of the leading /!
EDIT - Here is a Category extension to NSURL for your usage pleasure. It strips the initial "/" so you don't have an empty 0 index.
@implementation NSURL (ParseCategory)
- (NSArray *)pathArray {
    // Create a character set for the slash character
    NSRange slashRange;
    slashRange.location = (unsigned int)'/';
    slashRange.length = 1;
    NSCharacterSet *slashSet = [NSCharacterSet characterSetWithRange:slashRange];

    // Get path with leading (and trailing) slashes removed
    NSString *path = [[self path] stringByTrimmingCharactersInSet:slashSet];

    return [path componentsSeparatedByCharactersInSet:slashSet];
}
- (NSDictionary *)queryDictionary {
    NSDictionary *returnDictionary = [[[[self query] explodeToDictionaryInnerGlue:@"=" outterGlue:@"&"] copy] autorelease];
    return returnDictionary;
}
@end
share|improve this answer

difference between a strong and weak pointer


Objective-C (programming language): In Objective-C, what's the difference between a strong and weak pointer?

 (1)
 

2 Answers

Strong and weak are keywords that help you manage the Automatic Reference Counting (ARC) of the XCode environment and are a part of the new way of managing memory in Objective-C. To understand the difference, you must first understand how memory is implicitly managed by objects in XCode. 

Each object has a property that tracks the number of other objects that require/reference it. This property is called the reference count. In the old way of doing things, you would specifically tell the object to be retained (increase its reference count). When you did this, you would also have to explicitly tell the object to decrease its reference count (release) when you were done with it.

When an object’s reference count reaches zero, it is destroyed and its memory return to the heap where it can be reused. If you forgot to retain the object, it could potentially be destroyed earlier than you intended and cause an error in your program—there are reasons why you wouldn’t retain an object, but I’ll get into that further down. If you forgot to release the object, or your program was structured in such a way it could never be released, it could reside in memory long after you were done with it, causing a memory leak which could slow your app down or potentially crash it.

Now, with ARC you no longer have to explicitly tell an object to be retained or released. Pointers are automatically created with strong references; they are automatically retained. In this case, the strong keyword is implied when creating pointers, though you can use it if you want.

However there are times when you don’t want to retain an object (i.e. increase its reference count). To do this, you use the weak keyword when creating the pointer. Your pointer will still point to the object, but if that object is destroyed then using the pointer will cause a program error.

Why would you use a weak reference?

Well, one reason is if you have objects in parent-child relationships where the parent keeps pointers to its children and every child keeps a pointer to its parent. The potential with this structure is that you could no longer need your parent object and XCode will implicitly release it, but because its children keep a reference to it, the parent and its children can remain in memory even though you no longer have a way of accessing them. This is called a retain cycle.

To avoid the retain cycle, the children objects should only maintain a weak pointer to their parents. The reason for this is that when the parent is told to destroy itself, the children would be destroyed first so there is no chance they could access their parent after it had been destroyed.

atomic and noatomic


The last two are identical; "atomic" is the default behavior (note that it is not actually a keyword; it is specified only by the absence of nonatomic).
Assuming that you are @synthesizing the method implementations, atomic vs. non-atomic changes the generated code. If you are writing your own setter/getters, atomic/nonatomic/retain/assign/copy are merely advisory. (Note: @synthesize is now the default behavior in recent versions of LLVM. There is also no need to declare instance variables; they will be synthesized automatically, too, and will have an_ prepended to their name to prevent accidental direct access).
With "atomic", the synthesized setter/getter will ensure that a whole value is always returned from the getter or set by the setter, regardless of setter activity on any other thread. That is, if thread A is in the middle of the getter while thread B calls the setter, an actual viable value -- an autoreleased object, most likely -- will be returned to the caller in A.
In nonatomic, no such guarantees are made. Thus, nonatomic is considerably faster than "atomic".
What "atomic" does not do is make any guarantees about thread safety. If thread A is calling the getter simultaneously with thread B and C calling the setter with different values, thread A may get any one of the three values returned -- the one prior to any setters being called or either of the values passed into the setters in B and C. Likewise, the object may end up with the value from B or C, no way to tell.
Ensuring data integrity -- one of the primary challenges of multi-threaded programming -- is achieved by other means.

The last two are identical; "atomic" is the default behavior (note that it is not actually a keyword; it is specified only by the absence of nonatomic).
Assuming that you are @synthesizing the method implementations, atomic vs. non-atomic changes the generated code. If you are writing your own setter/getters, atomic/nonatomic/retain/assign/copy are merely advisory. (Note: @synthesize is now the default behavior in recent versions of LLVM. There is also no need to declare instance variables; they will be synthesized automatically, too, and will have an_ prepended to their name to prevent accidental direct access).
With "atomic", the synthesized setter/getter will ensure that a whole value is always returned from the getter or set by the setter, regardless of setter activity on any other thread. That is, if thread A is in the middle of the getter while thread B calls the setter, an actual viable value -- an autoreleased object, most likely -- will be returned to the caller in A.
In nonatomic, no such guarantees are made. Thus, nonatomic is considerably faster than "atomic".
What "atomic" does not do is make any guarantees about thread safety. If thread A is calling the getter simultaneously with thread B and C calling the setter with different values, thread A may get any one of the three values returned -- the one prior to any setters being called or either of the values passed into the setters in B and C. Likewise, the object may end up with the value from B or C, no way to tell.
Ensuring data integrity -- one of the primary challenges of multi-threaded programming -- is achieved by other means.

Friday, August 3, 2012

Android scale a Bitmap function


public static Bitmap getResizeBitmap (Bitmap img, int newWidth, int newHeight) {
double ratio = newWidth / img.getWidth();
ratio = (newHeight / img.getHeight()) < ratio ? (newHeight / img.getHeight()) : ratio;
Bitmap b2 = Bitmap.createScaledBitmap(img, (int) (img.getWidth() * ratio), (int) (img.getHeight() * ratio), true);
return b2;
}

Thursday, July 26, 2012

change android action bar title

Change with customized view


  // Set the custom section of the ActionBar with Browse and Search.
  ActionBar actionBar = getActionBar();
  View mActionBarView = getLayoutInflater().inflate(R.layout.actionbar_compat, null);
  actionBar.setCustomView(mActionBarView);
  actionBar.setDisplayOptions(ActionBar.DISPLAY_SHOW_CUSTOM);

Set the title text and icon 

getActionBar().setDisplayHomeAsUpEnabled(true);
getActionBar().setTitle(R.string.menu_done);
getActionBar().setIcon(R.drawable.btn_done);

Thursday, July 12, 2012

what is fips?


FIPS

Current NSS FIPS documentation:

NSS has completed FIPS 140 validation four times: 1997, 1999, 2002, and 2007.
August 27, 2007 NSS FIPS 140-2 level 2 cert was issued.
August 8, 2007 NSS FIPS 140-2 level 1 cert was issued.
Go to http://wiki.mozilla.org/FIPS_Validation for the plans and documentation of the recent NSS FIPS validation.

What is FIPS?

Federal Information Processing Standards Publications (FIPS PUBS) 140-1 and 140-2 are US government standards for implementations of cryptographic modules—that is, hardware or software that encrypts and decrypts data or performs other cryptographic operations. Additional FIPS standards govern cryptographic algorithms. Many products sold to the US government must comply with one or more of the FIPS standards. Some financial institutions informally consider FIPS validation an important seal of approval.
The FIPS standards for both cryptographic modules and cryptographic algorithms are maintained by the U.S. National Institute of Standards and Technology (NIST ). NIST runs a Cryptographic Module Validation (CMV ) Program that formally validates cryptographic modules for conformance to FIPS 140-1 or FIPS 140-2. FIPS validation under this program is a rigorous process that takes many months.
The NSS cryptographic module has been FIPS 140-1 validated under this program. Products that use NSS can highlight FIPS validation as a widely acknowledged indication of high standards and rigorous testing, especially if they are intended for use by federal agencies and financial institutions.

NIST Cryptographic Module Validation Program

NIST's Cryptographic Module Validation Program page is a good starting point for the various FIPS standards for cryptographic modules and algorithms, the testing requirements, implementation guidance, and validation lists .
The most important FIPS cryptographic standard is 140-1 or 140-2, which covers the security requirements for cryptographic modules. (140-2 is a replacement for 140-1. After May 25, 2002, NIST will only accept validation reports against 140-2.) Implementation of the cryptographic algorithms used by the cryptographic modules to meet the requirements of FIPS 140-1 or 140-2 also need to be validated against their respective FIPS standards.

FIPS Validation of the NSS Cryptographic Module

The FIPS validation status of the NSS cryptographic module can be verified with the validation lists on NIST's web site. The FIPS validation history of the NSS cryptographic module is summarized in chronological order in the table below. Scanned in images of the validation certificates will be available soon.
Module
Algorithm
Standard
Certificate
Netscape Security Module 1
Netscape Communications Corp.
FIPS 140-1 Level 2
Certificate #7
08/29/1997
(ALG DES) v1.8,DES
FIPS 46-3, FIPS 81
Certificate #6, 03/14/1997
(ALG 3 DES) v1.8, Triple DES
FIPS 46-3, FIPS 81
Certificate #10, 07/02/1997
(ALG DSA) v 1.3, DSA & SHA-1
FIPS 186-2
Certificate #3, 03/26/1997
Netscape Security Module 1.01
Netscape Communications Corp.
FIPS 140-1 Level 1
Certificate #45,03/17/1999
FIPS 140-1 Level 2
Certificate #47,03/17/1999
(ALG DES) v1.9 DES
FIPS 46-3, FIPS 81
Certificate #33,07/09/1998; 09/11/1998.
v1.9 (ALG 3 DES), Triple DES
FIPS 46-3, FIPS 81
Certificate #34, 07/09/1998;
09/11/1998
(DSS v1.4; SHS v1.13), DSA & SHA-1
FIPS 186-2
Certificate #14, 07/29/1998,
09/28/1998
Network Security Services,
Version 3.2.2
Sun Microsystems
FIPS 140-1 Level 1
Certificate #247,08/30/2002
FIPS 140-1 Level 2
Certificate #248,09/04/2002
FIPS 46-3 and FIPS 81
Certificate #133, 08/24/2001
Triple DES
FIPS 46-3
Certificate #72, 08/24/2001
SHA-1
FIPS 180-1
Certificate #70, 11/06/2001
FIPS 186-2
Certificate #52, 11/06/2001
Network Security Services,
Version 3.11.4
Red Hat and Sun Microsystems
FIPS 140-2 Level 1
Certificate #815, 08/2007

FIPS 140-2 Level 2
Certificate #814, 08/2007
FIPS 197
Triple DES
FIPS 46-3
SHS (SHA-1, SHA-256, SHA-384, SHA-512)
FIPS 180-2
FIPS 198
FIPS 186-2 with Change Notice 1
FIPS 186-2 with Change Notice 1
RSA (RSASSA-PKCS1-v1_5)
PKCS #1 v2.1
ECDSA
FIPS 186-2 with Change Notice 1
Certificate #30, 06/2006
Certificate #37, 10/2006