Duplicate ID, tag null, or parent id with another fragment for com.google.android.gms.maps.MapFragment

I was using Google map API version2 with for one of my application.In layout I was using "com.google.android.gms.maps.MapFragment".

 <RelativeLayout
                        android:id="@+id/relative_disc_nyc_map"
                        android:layout_width="fill_parent"
                        android:layout_height="fill_parent" >

                        <fragment
                            android:id="@+id/frg_disc_nyc_map"
                            android:layout_width="fill_parent"
                            android:layout_height="fill_parent"
                            class="com.google.android.gms.maps.MapFragment" />
             </RelativeLayout>

And while executing I was using the above layout and adding it into fragment.....

public class DiscoverNYCActivity extends Fragment {
    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
View rootView = inflater.inflate(R.layout.activity_discover_nyc, container, false);
        lbl_poi_title = (TextView) rootView.findViewById(R.id.lbl_poi_title);
        lbl_rate_count = (TextView) rootView.findViewById(R.id.lbl_rate_count);
return rootView;
}

But when I was travesing to the sam e screen twice.I was giving me below error

06-07 14:41:41.496: E/AndroidRuntime(21037): FATAL EXCEPTION: main
06-07 14:41:41.496: E/AndroidRuntime(21037): android.view.InflateException: Binary XML file line #120: Error inflating class fragment
06-07 14:41:41.496: E/AndroidRuntime(21037): at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:719)
06-07 14:41:41.496: E/AndroidRuntime(21037): at android.view.LayoutInflater.rInflate(LayoutInflater.java:761)
06-07 14:41:41.496: E/AndroidRuntime(21037): at com.wf.wholesale.nymta.DiscoverNYCActivity.onCreateView(DiscoverNYCActivity.java:101)
06-07 14:41:41.496: E/AndroidRuntime(21037): at android.support.v4.app.Fragment.performCreateView(Fragment.java:1500)
06-07 14:41:41.496: E/AndroidRuntime(21037): Caused by: java.lang.IllegalArgumentException: Binary XML file line #120: Duplicate id 0x7f090058, tag null, or parent id 0x7f090057 with another fragment for com.google.android.gms.maps.MapFragment
06-07 14:41:41.496: E/AndroidRuntime(21037): at android.app.Activity.onCreateView(Activity.java:4971)
06-07 14:41:41.496: E/AndroidRuntime(21037): at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:695)
06-07 14:41:41.496: E/AndroidRuntime(21037): ... 24 more

The problem is that what I was trying was wrong. You shouldn't be inflating fragments inside other fragments. From Android's documentation:

Note: You cannot inflate a layout into a fragment when that layout includes a <fragment>. Nested fragments are only supported when added to a fragment dynamically.

I have resolved the error with below changes.....

public class DiscoverNYCActivity extends Fragment {

View rootView;

    @Override

    public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {

 if (rootView != null) {

           ViewGroup parent = (ViewGroup) rootView.getParent();

           if (parent != null)

               parent.removeView(rootView);

       }

       try {

        rootView = inflater.inflate(R.layout.activity_discover_nyc, container, false);

       } catch (InflateException e) {

            map is already there, just return view as it is 

       }

        lbl_poi_title = (TextView) rootView.findViewById(R.id.lbl_poi_title);

        lbl_rate_count = (TextView) rootView.findViewById(R.id.lbl_rate_count);

return rootView;

}

Eclipse Error : Using 1.7 requires using Android Build Tools version 19 or later; currently using 17.0.0 ?

The project shows this error when relevant build tool is not set for the Project.
First goto Eclipse-->Windows--->Android SDK Manager and installed the relevant build tool required by the application.After installation is completed close the SDK manager.

Then add the below line in "project.properties" file of then prject.Error will be resolved.

sdk.buildtools=19.1

Android Host Card Emulation(HCE) in 4.4 ?

 FAQ

Q> What is HCE?

A> Host-Based Card Emulation

Er... whats that??

Before we talk about HCE (Host-Based Card Emulation) we must understand what is CE (Card Emulation)

Card Emulation is as it says emulation of a card (CreditCard/ ID Card/ Loyalty Card / any card) over NFC interface of a mobile phone.

In this mode a mobile NFC can exchange APDU (Data) with the a POS (Payment Terminals) or any other Terminal (eg. Security Machine on Doors or a Time punching machine for your office )

Alright!! I understand NFC but whats Card Emulation?

A card in this refers to a an environment which is created with the help of secure element, and applets.

Woaahhh 2 NEW TERMS!!!

Secure Element:  In simplest words.. Its a memory + processor + Mini OS which is out of phone OS, is highly restricted for access and is believed to be non-hackable!

Applets: Nothing more than small Java Programs which can run on this Mini OS of Secure Element. Which communicates based on Hexadecimal Commands also known as APDU.

So when you use your credit card or even a sim card remember "YOU GOT THE POWER" of secure element in your hands. Yeah that a freaking complete Operating system which is super secure in your hand.

Ok.. so??

So Card Emulation basically says that in order to communicate with this Card (Secure Element + Applets) the Phone NFC will accept the commands, will send these commands to Card residing somewhere in the phone and then will forward the responses generated from this Card over NFC interface back to the terminal.(See Dig.2)

Now to ease things up Card can be present in 3 of these location

1. Embedded Secure Element

2. SDCard based Secure Element

3. UICC (SIM Card)

Kool!! then why do we need HCE?

The biggest advantage is also the biggest disadvantage for Secure Element, being highly restricted, any addition of deletion of data needs heck of approvals from the provider of these.

For example: In case of UICC based Secure Element, only the MNO (mobile Network Operator) who owns a SIM card is authorised to put your CreditCard data inside the secure element, BUT, the CreditCard belongs to a Issuer (Bank) therefore in-order to put one simple CreditCard inside a secure element you need Bank and MNO to come together and work together. No wonder you don't see many application which uses any of these technologies.

Now with HCE, there is no need for Secure Element, I mean you can work even without them.

Now the data can directly be sent and received by an application, your own phone application.(See Dig.3)

Overview on Host Card Emulation (HCE)

HCE is an open architecture that allows mobile applications to emulate a contactless smartcard. Unlike traditional NFC transactions that rely an embedded or SIM card Secure Element (SE), HCE is a purely software-based solution. This new approach is significant for the industry because: 1) it takes control away from mobile network operators (MNOs) who control access to a mobile device’s SE and, 2) it creates new possibilities for using a phone’s NFC feature.

Host Card Emulation (HCE) as an exciting development for the NFC market because it provides an additional means by which to perform NFC transactions. With HCE, transactions take place using credentials stored in the cloud or on the host processor of the NFC-enabled mobile device rather than a tamper resistant Secure Element, such as an embedded security chip, SIM, or microSD card.

HCE works by storing payment credentials on a remote cloud rather than the SE (see Figure 1). Conceptually, a mobile application could be programed to send requests to allow access to these credentials via a secure token. This token would then be passed via the phone’s NFC antennae to another contactless reader to complete a payment transaction. A key requirement is ensuring that the token is recognized by the reader as a valid payment credential.

Dig.1

This development may prove troubling to some mobile wallets, like the Mobile Network Operator-led Isis, which relies on the SE approach.Isis currently requires card issuers to integrate with a Trusted Service Manager (TSM) to facilitate access to a device’s SE.HCE provides an alternative to TSM integration, which can be expensive and time consuming. To date, only a few European banks have explored HCE deployment, but there are service providers that are prepared to enable similar solutions in the U.S. market. Visa and MasterCard have also independently announced their intentions to provide software development kits (SDKs) that would allow issuers and other potential wallet providers to write HCE applications that conform to the existing contactless payment specifications.

Host Card Emulation (HCE) as an exciting development for the NFC market because it provides an additional means by which to perform NFC transactions. With HCE, transactions take place using credentials stored in the cloud or on the host processor of the NFC-enabled mobile device rather than a tamper resistant Secure Element, such as an embedded security chip, SIM, or microSD card.As the definition suggests, it is an emulation of a contactless smart card. What is the capability of a contactless smart card? Mainly payment, identification and transportation. What happens when one of these cards, say your id card, which you use for entering your office building is just an app on your mobile phone? Or your contactless credit/debit card? Sounds intriguing.

Before HCE, contactless smart card was being emulated by a hardware chip and software (mobile app) was needed for the hardware to be activated. Hardware component was either a chip embedded on the phone or the SIM card. Either way, a few more parties other than the owner of the handset itself was involved in the game and it was quite complicated to activate and use the NFC app. Now with the HCE, smart card is still being emulated but this time it is software rather than the hardware.

In the hardware mode, contactless (NFC) reader was working with the secure element.

 Dig.2

Now with the HCE, hardware component -SE or the embedded chip is not needed. Android itself emulates the hardware. Apps will use the interface provided by the operating system again but this time there is no hardware below the API.

Dig.3

How to Load Apps or Apk on Google Glass ?

For this tutorial we will show you how install Google Sky (also known as stardroid) without rooting your Glass or swapping roms. This is the same basic procedure you would go through to manually load an app on an Android phone, but since Google Glass has a limited amount of input, the specific app you install matters. 

Before we begin it is important that you already have the Android SDK, most importantly you need ADB (android debug bridge). You also need to be somewhat familiar with opening a new terminal window. We will work for Linux and might need a little modification for Windows. We also assume you download files to your home Download directory, but you can change this as needed. (~/Downloads)

Download and Install the Android SDK (http://developer.android.com/sdk/index.html). We find it helpful to have adb in your PATH so you can call it from anywhere (you may want to add it to your .bashrc or whatever you are using).

export PATH=$PATH:~/Downloads/adt-bundle-mac-x86_64-20130514/sdk/platform-tools

First things first, Put your Glass in “Debug Mode” in the settings on the Glass itself. Locate the device info and scroll right to turn Debug Mode on. Then plug your Glass into your computer using the USB micro cable.

Now grab a version of Google Sky that you want to install (this is the same for any Android .apk file).

wget http://file.appsapk.com/wp-content/uploads/apps-2/Google%20Sky%20Map.apk

Simply load the .apk file onto the Glass with adb.

adb install ~/Downloads/Google\ Sky\ Map.apk

After the .apk is loaded onto Glass you now need to use adb shell to run it. The trick here is that you need to figure out what Activity to run. You can use the adb command dumpsys to discover a plethora of information about your Glass. You can figure out the main activity for the .apk with a little help from grep, and since it was the last thing loaded we can also narrow this information down with a tail command.

adb shell dumpsys | grep android.intent.action.MAIN | tail -n 2

This might take some time depending on your system, but it will eventually return something similar to this:

intent={act=android.intent.action.MAIN flg=0×10000000 cmp=com.google.android.stardroid/.activities.SplashScreenActivity}

android.intent.action.MAIN:

You now have the right information to start the app on Glass. We use the am command to start the app on Glass. Simply reformat the Activity call to follow the same format as the stardroid example call below:

adb shell am start -a android.intent.action.MAIN -n com.google.android.stardroid/com.google.android.stardroid.activities.SplashScreenActivity

At this point tap your Glass on and the app should be running. You will need to “down swipe” on your glass to cancel the agreement window. If you see the app running, disconnect, go outside, and check this out at nighttime! Warning: you may feel like a terminator with some kind of super power.

Note: this is not part of the Official Glass Mirror API that is displayed on your timeline and running apps full time like this is a drain on the battery, which is not in Google’s application design guidelines. It merely demonstrates how to sideload an app on Glass in your terminal without voiding your warranty.

How to get SHA certificate in Windows ?

C:\Program Files (x86)\Java\jdk1.6.0_06\bin>keytool -v -list -keystore C:\Users\sshukla\.android\debug.keystore -alias androiddebugkey -storepass android -keypass android
Alias name: androiddebugkey
Creation date: Apr 18, 2013
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Android Debug, O=Android, C=US
Issuer: CN=Android Debug, O=Android, C=US
Serial number: 64bbfdff
Valid from: Thu Apr 18 14:56:16 IST 2013 until: Sat Apr 11 14:56:16 IST 2043
Certificate fingerprints:
         MD5:  75:73:CC:22:4C:C0:EB:04:6A:C5:63:89:57:66:DC:DB
         SHA1: 8A:C7:3A:96:2E:4E:D2:F0:C6:B0:AB:1D:A2:FE:DA:6E:E2:71:8F:CD
         Signature algorithm name: SHA256withRSA
         Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: EF 85 F0 F3 11 65 7A D3   C7 66 10 21 BE 85 DB 69  .....ez..f.!...i
0010: 8B 9A 7A 07                                        ..z.
]
]


C:\Program Files (x86)\Java\jdk1.6.0_06\bin>

APNS SSL Error - javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure?

1. Created certificates from mac machine
2. in tomcat server application using JavaPNS to send the notification
Used Push.alert(...) used .p12 file


javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

I finally find the problem is due to the p12 certificate. We should not use the private key p12 file, instead we
should generate a p12 from your private key and the cert download from Apple.

Please execute the following OpenSSL command to get the correct p12 file

developer_identity.cer <= download from Apple
mykey.p12 <= Your private key

1) openssl x509 -in developer_identity.cer -inform DER -out developer_identity.pem -outform PEM
- developer_identity.cer = the .cer file obtained from developer.apple.com site.
- developer_identity.pem = the "PEM" output file name.

2) openssl pkcs12 -nocerts -in mykey.p12 -out mykey.pem.
- mykey.p12 = the (.p12) file obtained initially from exporting (.cer) file.
- mykey.pem = the "PEM" output file name.

3) openssl pkcs12 -export -inkey mykey.pem -in developer_identity.pem -out iphone_dev.p12
- mykey.pem = the "PEM" file obtained in step (2).
- developer_identity.pem = the "PEM" file obtained in step (1).
- iphone_dev.p12 = the final (.p12) file, to be used at backend server side.

After that, you should use iphone_dev.p12 to communicate with apple server.

Convert Seconds into HH:MM:SS in java?

Below are the methods to convert seconds into minute seconds format...


int day = (int)TimeUnit.SECONDS.toDays(seconds);      
long hours = TimeUnit.SECONDS.toHours(seconds) - (day *24);
long minute = TimeUnit.SECONDS.toMinutes(seconds) - (TimeUnit.SECONDS.toHours(seconds)* 60);
long second = TimeUnit.SECONDS.toSeconds(seconds) - (TimeUnit.SECONDS.toMinutes(seconds) *60);
 System.out.println("Random Element "+minute+":"+second);

OR 

public static void calculateTime(long seconds) {
   int day = (int) TimeUnit.SECONDS.toDays(seconds);
   long hours = TimeUnit.SECONDS.toHours(seconds) -
                TimeUnit.DAYS.toHours(day);
   long minute = TimeUnit.SECONDS.toMinutes(seconds) -
                 TimeUnit.DAYS.toMinutes(day) -
                 TimeUnit.HOURS.toMinutes(hours);
   long second = TimeUnit.SECONDS.toSeconds(seconds) -
                 TimeUnit.DAYS.toSeconds(day) -
                 TimeUnit.HOURS.toSeconds(hours) -
                 TimeUnit.MINUTES.toSeconds(minute);
   System.out.println("Day " + day + " Hour " + hours + " Minute " + minute + " Seconds " + second);
}