JPasswordField under android

by jaafar zbeiba » Sat, 12 Mar 2011 04:21:48 GMT


Sponsored Links
 hello I use a JPasswordField but I have a problem with java.awt.event
and java.swing

package com.example.tuto;

        import javax.swing.*;
        import java.awt.*;
        import java.awt.event.*;

        public class  Password()  extends JFrame implements ActionListener {

                JPasswordField pass;
                JButton test = new JButton("get");

                public Password(){
                        JPanel pane = new JPanel();
                        test.addActionListener(this);
                        pane.setLayout(new FlowLayout());
                        pane.add(pass = new JPasswordField(15));
                        pane.add(test);
                        setContentPane(pane);
                        setVisible(true);
                }

                public void actionPerformed(ActionEvent evt) {
                        Object source = evt.getSource();
                        if(source == test) {
                                char[] tet = pass.getPassword();
                                System.out.println(new String(tet));
                        }
                }

                public static void main(String[] args) {
                Saisir p = new Saisir();
                }

        }
help me please thxx

-- 



Re: JPasswordField under android

by Justin Anderson » Sat, 12 Mar 2011 05:08:41 GMT


 Ummm.... swing and awt are not included with Android.


Thanks,
Justin Anderson
MagouyaWare Developer
 http://sites.google.com/site/magouyaware 


On Thu, Mar 10, 2011 at 2:44 PM, jaafar zbeiba <jaafarinformati...@gmail.com




-- 


Sponsored Links


Other Threads

1. yaffs2 and streams

My understanding is that the Android will be using the yaffs2 file
system.  Is that correct?

If so, I have a question about how it handles failed stream
operations.  I'm writing a small app that can potentially do a lot of
I/O using file streams.  On some environments, I've noticed that under
high CPU situations, the occasional stream operation fails:  for
example, a call to mystream.write(buffer, 10) might fail, or a call to
"mystream << buffer".

I know it fails because mystream.fail() returns true after the call.
However, what I don't know is the extent of the failure.  Did none of
the bytes make it through?  Or two bytes, or nine?

The errno is 0 and so far in my testing, none of the bytes make it
through.  However, I don't know if this is always the case thanks to
yaffs journaling, or whether this is just luck and partial output of
the stream is just rare but possible with my application.

Does anyone know if I can/should rely on the journaling to ensure that
none of the bytes in the failed call makes it through, or if I need to
put in some sort of rollback mechanism in my code to gaurantee this?

--~--~---------~--~----~------------~-------~--~----~

2. Wall Street Journal article today - are things going down the drain for independent developers?

The WSJ has an article today about the state of the affairs in the
Android empire.
http://online.wsj.com/public/article/SB121418837707895947.html?mod=2_1571_leftbox
Looks like the journalists made a number of phone calls and did not
just regurgitate some blogs - some solid insights into carriers and
developers' current situation, it seems. I have the following
takeaways from the article:
- For app developers, there is a world of two speeds. If you got "in"
through the Challenge or some other relationship, you already have
access to information about the next SDK, draft release notes at the
minimum, probably the SDK itself. Nothing in sight to the public
though. Or did I miss something? The WeatherChannel developer anyways
indirectly confirms this, which means they are getting a headstart to
implement the necessary changes to their apps, while everybody else
has to sit and wait.
- Carriers are busy branding "their" Android. Worst case, we can
expect subsidized-only phones a la iPhone, which only include apps
which made it on the inside track, while independent developers cannot
load and test theirs (superficial carrier explanation here: copy Steve
Jobs excuses of yore). The first batches of Android phones will
certainly come with aggressive SIM locks - no question in my mind, but
I might be proven wrong.
It'll be interesting to see however if enthusiasts can flash these
suckers from clean Android images without too much trouble. Sans SIM
lock, sans branding, but I suspect special service cables will be
needed which are not available to the public. Needless to say that
we'll be told we'll burn in hell (or worse) if we choose to pursue
this.

Overall... question marks keep piling up for independent developers.
Looks like we are getting squeezed out of the race to market? Perhaps
some clarifying words by the developer advocates at Google might give
us some pointers (wink, wink)?

JP

--~--~---------~--~----~------------~-------~--~----~

3. Error in creation of new android project

4. How to play a VideoFile from Resourse Folder??

5. Show a (progress) dialog in the onClick event of an alert dialog

6. No display, was: Wall Street Journal article

7. Webkit(Webview) & IME