Agreed, and for many applications, I prefer JSON. If I'd designed
XML, it would have been a lot simpler.
Still, using JSON for this would need some naming convention to avoid
name collisions.
A big advantage that XML has is that there are a lot more tools
available for XML than for JSON. So you
I'd suggest using a trie, if the data is static, or mostly static. (If
you need to add additional words, you can stick them in a splay tree).
It's fast, it's simple. It can be constructed in a way that it can be
encoded as a byte array, and relevant portions read from a file,
rather than loading
Just an observation, though perhaps not that useful for you
This is exactly what trademarks are intended to address.
A suitable threatening letter MIGHT have some small chance of
working. Taking the step of registering your trademark might even be
worthwhile.
But actually getting him to
It seems to me that, from a platform design point of view, this
approach is backwards.
It really shouldn't be the notifier's responsibility to check for
recording. It should be the recording app's job to turn off
notification and other unwanted sounds during recording.
So I wonder if you could
Try recompiling the libraries with Java 1.5, or with a Java 1.5
compilation target.
You may have other problems doing this as well. Android does not
include all of the classes present in JavaSE.
On Mar 4, 11:14 am, MikeK michael.ko...@gmail.com wrote:
I have some well-debugged XML-RPC
The Javadoc says horizontal accuracy, as EGO says; I dunno why I
missed that before. But it's consistent with my observations.
But you're dependent on the GPS implementation in the device, and how
they implement and report the accuracy computation may vary. If you
REALLY care, I'd suggest
.
No doubt, eventually Android will have a similar tool. But disassembly
is plenty good enough to reverse-engineer things.
On Mar 3, 7:16 pm, fadden fad...@android.com wrote:
On Mar 3, 6:09 am, Bob Kerns r...@acm.org wrote:
Re: JDASM -- that works on standard Java byte codes -- which aren't
present
Just a small terminology clarification
BKS refers to the Bouncy Castle keystore format, rather than the type
of certificate (which will always be an X509 certificate).
The keystore is the container in which certificates and keys are
stored. I'm not sure why both Sun and Bouncy Castle
My guess is that you never gave tcpdump execute permission.
Try (as root) chmod 555 tcpdump
On Mar 4, 1:38 am, Houcem Berrayana houcem.berray...@gmail.com
wrote:
Hi,
I rooted my Motorola Cliq successfully in order to start using
tcpdump. I copied tcpdump inti /system/bin.
And I am logged in
You can't do that, any more than you can connect from your home PC to
my home PC. We're probably both behind NAT firewalls, with IP
addresses that can't be used on the public internet.
Actually, my T-Mobile phone has a publicly-routeable IP, while my ATT
does not. But the bottom line is, at the
It's more than that. There's no reason for there to be any routes for
anything except phone to APN, and no reason for them to not filter out
all incoming requests and inter-phone traffic as a security measure.
You can't persuade your cable modem to let you talk directly to your
neighbor, either.
Check the Javadoc. SmsMessage was introduced in API level 4 (1.6). It
doesn't exist in 1.5 (API level 3).
On Mar 4, 8:39 pm, g1bb corymgibb...@gmail.com wrote:
Hello,
I've come across a strange problem reported by an HTC Droid Eris user,
and all testing on the other SDK's shows it to be fine.
It's simple -- they don't. Instead, the device accesses a server
periodically.
It's possible to jump-start the process with an SMS message, rather
than blindly polling. This also saves considerable battery power.
See, for example: https://labs.ericsson.com/apis/mobile-java-push/downloads
The
Each application that wants to run must implement a
android.intent.action.BOOT_COMPLETED broadcast receiver, and have the
android.permission.RECEIVE_BOOT_COMPLETED permission.
You probably don't actually want to know about the actual set of
running processes -- just how to get your application to
Re: shared library in C: Not hard at all.
Re: packet sniffers and man-in-the-middle -- not if you use the HTTPS
protocol properly. That's why it exists. On the other hand, with
physical access to the device, you could replace the HTTPS libraries
and get the same result.
Re: JDASM -- that works
Google is your friend. Asking Google usually gives you better answers
than posting questions.
http://tinyurl.com/ygkfdry
One of them (the third one when I try it, by a guy named Tom Gibara)
makes it too simple, really. You really SHOULD make an attempt to
learn both how Twitter works and how
Is there something wrong with the one built into the system???
http://developer.android.com/intl/de/reference/org/json/package-summary.html
On Mar 3, 4:53 am, Michael Davey frak@gmail.com wrote:
I don't suppose you can give me a URL to your JSON serializer? That would
help me out a lot
It's only a single XML file if you use a single shared preference
object.
You don't actually have to use the default one. If it does simplify
your life, you can use this:
http://developer.android.com/intl/de/reference/android/content/Context.html#getSharedPreferences(java.lang.String,
int)
...to
I can just share my observation that on my Nexus One, it's generally
off by more than that, vertically. But most of my testing has been
indoors, and that should make the satellites look a bit further away,
so that may be the reason.
Depending on how much you care, the best answer may be to take
You mean, are there any 2.1 devices out there besides the Google Nexus
One?
If your app works OK with API 7, then declare it as targeting API 7
(while keeping the minSDKversion at 3), and it won't operate in
compatibility mode.
On Mar 3, 6:18 am, Neilz neilhorn...@googlemail.com wrote:
Firstly,
. The 'targetSdkVersion' and 'maxSdkVersion'
statements were introduced in level 4.
All my apps state minSdkVersion as 3 (as I have a 1.5 phone and so do
lots of my users) so I cannot tell it to target a level 7 device.
On Mar 3, 4:41 pm, Bob Kerns r...@acm.org wrote:
If your app works OK with API 7
?? If you have verified this, please report it as a bug.
The way GC works, GC work should be triggered by any allocation that
needs more memory (incremental algorithms trigger some amount of GC
work on each allocation, non-incremental algorithms do ALL the work in
this situation). The allocation
Generally, non-compacting GCs, and non-compacting/consolidating
allocators in general, cannot free memory back to the OS once it's
been used.
There are exceptions, such as when the object size is significantly
larger than the minimum OS memory allocation size. (By OS here, I
mean whatever lower
, Greg Donald gdon...@gmail.com wrote:
On Wed, Mar 3, 2010 at 6:21 PM, Bob Kerns r...@acm.org wrote:
?? If you have verified this, please report it as a bug.
To who? The same Google engineers that can't fix my Marketplace stats
since December?
http://www.google.com/support/forum/p/Android
about GC is that you can usually ignore it without
paying too much of a price -- but not always.
On Mar 3, 7:09 pm, fadden fad...@android.com wrote:
On Mar 3, 4:33 pm, Bob Kerns r...@acm.org wrote:
Generally, non-compacting GCs, and non-compacting/consolidating
allocators in general, cannot
can sometimes alleviate these problems.
I wish I'd said it that way to begin with.
On Mar 3, 10:00 pm, Bob Kerns r...@acm.org wrote:
The key word here is 'generally', which I guess wasn't clear. What I
was trying to get at is, it can only happen under specific
circumstances, and only
Yeah, I finally realized I hadn't posted there before (odd, but true)
and that was probably what was going on.
I'm being patient -- I was just letting y'all know, since I had posted
here that I had posted there...trying to minimize the confusion.
Al Sutton wrote:
Bob,
If it's your first post
I think we need to help you clear up your model of the language. I've
been trying to figure out what computer language is your main
language, but I can't quite figure it out -- but it's not Java, I
don't think. If you tell us, maybe we can explain a bit better, but
I'll give it a shot anyway.
At
Thanks for raising this -- I hadn't considered the problem.
My understanding is that in some places, it's the country that is the
source of the restrictions (i.e. legal barriers to Google Checkout or
something like that), while in other places, that barrier doesn't
exist, but carriers impose
If I'm interpreting your pattern correctly, you're invoking activity A
from activity B, and activity B from activity A?
That would explain your problem, at least.
Instead of invoking A from B -- return to A by finishing B. Then
you'll only every have one A, and at most one B active at a time.
My take on it is that he wants to create one from inside an Android
app, and doesn't understand that the question is not at all specific
to Android. (And further, that he didn't give us enough context to
help anyway).
It would be more useful to politely point out (rather than as
rhetorically)
, but
say what you googled and why that didn't help.
Googling is a skill that needs practice. Try to build yourself a pool
of resources -- a set of bookmarks of useful places to look for
answers.
On Mar 1, 11:55 am, TreKing treking...@gmail.com wrote:
On Mon, Mar 1, 2010 at 12:17 PM, Bob Kerns r
But I wasn't able to launch an emulator at a mere 1336x678, either,
not even with allocating 1GB RAM for the device an 128MB for the app
heaps. The system_server dies in the SurfaceFlinger in libEGL.so.
I suspect the thing to do is to capture the error with adb -e logcat
(which is how I observed
I responded to you, Mark, and Al over there yesterday, but nothing has
shown up. Perhaps I'm on moderation separately over there, as I've
not posted there before.
I'd rewrite the messages, no doubt better the second time, but that
would probably be incredibly confusing... :)
Bob Kerns wrote
And the good aspects of the current market would be? Besides not
having an Apple-style lock-in?
Seriously -- if I were a Google engineer, I would be a little offended
by your message. Personally, I give them more credit for being adults,
and not needing their feelings protected.
Nobody is
I don't, in fact, understand their predicament.
I presume they have one. They haven't communicated it, so I won't
pretend to understand it.
I'll settle for helping them understand my predicament, and hope they
can use that effectively in balancing their predicament.
Could you please identify in
This assumes facts that, as near as I can tell, are not in evidence.
In fact, I expect they hold these cards rather close to their chest.
But we don't need to know. The point to be made here is simple (and
this could be more clear, I think):
This 30% -- which we assume is profitable in some way
this property of
the font successfully to type it through the default virtual
keyboard, on to my Message Box(Edit Text).
Thanking You,
Regards,
Srikant Aggarwal
On Feb 26, 11:26 pm, Bob Kerns r...@acm.org wrote:
The Unicode Consortium has not addressed non-human languages
Thanks, John, I think this is a lot more helpful -- even if I don't
entirely agree.
But I'm following Mark's lead and posting my response over on android-
discuss.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send
The Unicode Consortium has not addressed non-human languages. Not even
Klingon, whose script has been around for 30 years, even longer than
Unicode!
But if you Google unicode klingon, you can find how people have
addressed this for Klingon, e.g. using the Private Use area.
I'd also look around
Reflection is an old computer language term. Think of it as
referring to the ability of a language to see itself, as in a mirror.
Languages such as C and C++ don't have it. Java, Lisp, and many
scripting languages do.
On Feb 25, 8:46 pm, Nick Owens nicow...@gmail.com wrote:
All:
So I realized
I take it a step further, and send one event for each exception cause
(up to three).
I also process the stacktrace to make it more compact (taking out
filenames, removing package prefixes that I expect, etc.) so that more
trace fits within Flurry's limits.
I find it useful already, even though my
I think in this situation, the IMEI is a better choice for identifying
when a trial has expired. You'd like to let them try your app on their
new fancy faster phone with the bigger screen!
The ANDROID_ID is a better choice (if it really is tied to the account
and not the phone?) if you're
'
xd:doc xmlns:xd=http://www.oxygenxml.com/ns/doc/xsl;
scope=stylesheet
xd:desc
xd:pxd:bCreated on:/xd:b Feb 24, 2010/xd:p
xd:pxd:bAuthor:/xd:b Bob Kerns/xd:p
xd:p/xd:p
/xd:desc
/xd:doc
xsl:param name=VERSION/
xsl:param name
My business partner and I have a small disagreement, and I'm trying to
figure out the best way to resolve it.
First, I should say I started out his way, and switched after
reviewing a lot of applications.
The background is this -- we have an app, with some controls which can
be locked. A
-developers@googlegroups.com
[mailto:android-develop...@googlegroups.com] On Behalf Of Bob Kerns
Sent: Friday, February 26, 2010 5:11 PM
To: Android Developers
Subject: [android-developers] Usability: State vs Verb
My business partner and I have a small disagreement, and I'm trying to
figure out
with
changing it; I just don't want to change it without any idea of what
I'm doing.
Most of the functionality is available without the context menus.
Thanks, guys.
On Feb 26, 2:21 pm, Mark Murphy mmur...@commonsware.com wrote:
Bob Kerns wrote:
If the user sees the state on the main activity
...@googlegroups.com] On Behalf Of Bob Kerns
Sent: Friday, February 26, 2010 5:29 PM
To: Android Developers
Subject: [android-developers] Re: Usability: State vs Verb
?Huh? You're saying my menu option should be BLANK except for the
checkbox if not locked???
I'm sure I'm misreading you.
I do get
Then it's not a 9-patch! A 9-patch has one extra pixel around the
edge, that is used to describe where the graphic within that 1-pixel
border is stretched.
Please see the documentation for the Draw 9-patch tool, which can take
an existing graphic and convert it for you, by adding those 1-pixel
While the downloadable license approach sounds good on the face of it,
there are just too many loose ends for my tastes as it stands. We
already have a very limited channel for communicating with our
customers, and I don't want to waste those characters
What I've done is create a master build
This would be a bug in the JNI code, which is responsible for
protecting from the GC any and all memory which it is using. Only it
can do so, because only it knows when it is done.
That's unlikely, though. The the JNI API makes it impossible to get
your JNI code to get its hands on the data
Exit the loop, remembering your index. Arrange to restart it at the
appropriate time -- an Alarm, or a message posted by whatever code you
were waiting to be done.
You don't ever want to actually pause or sleep in the main thread.
Your entire App will appear to freeze.
On Feb 25, 12:33 am, CMF
The reason I'm leaning toward using a provider is because it
simplifies dealing with different versions of the from application.
Not perfectly, of course, and there's other ways to accomplish the
same thing. Since these are essentially the same app, a little
intimate knowledge of the inner
If you want to handle the case where the app has been uninstalled and
reinstallled, I think your best bet is to store activation data off-
device via the network.
A fairly secure way of doing this is to create a Certificate Request
to your server, including your device ID in the DN, and send back
Normally, running out of memory wouldn't cause a stack overflow, but
it could happen if it causes you to get an error handling the error
handling the error handling the error handling the error...
You may need to adjust the memory allocation for Java.
If, in your Eclipse install, you open
It's similar to how you do it on the PC, except the eclipse.ini file
lives inside the application bundle. I haven't used a Mac in about 4
months, so I won't try to guide through the menus to look inside the
application bundle from the Finder.
I think you can also specify it somehow in the app's
Check out the APIs in android.wallpaper.service. That's your starting
point.
On Feb 22, 11:52 pm, Janam janamjhav...@gmail.com wrote:
Hi,
I'm trying to figure out a way to hold RSS feeds in the wallpaper. How
can I have the wallpaper hold/display content and not just an image?
Is this even
I think you mean Code Assist? I've noticed (over many Eclipse
revisions) that when Eclipse starts to get bloated, Code Assist stops
working.
I don't know if it's getting some internal error, or just running out
of memory to do its stuff.
Either way, the solution I use is to exit Eclipse, and
Um, yeah -- and don't forget to apply the same degree of care to the
keystore and alias passwords!
I caused myself a bit of panic the other day, when I changed the
passwords prior to automating my builds -- and forgotten I'd done so.
Fortunately (sort of), I don't have any apps in the store yet,
I just went and reread the documentation. It's not as precise on this
point as I would like to see.
You CAN, in fact, create a new certificate IF AND ONLY IF you have the
original private and public keys. The question is, can you use it?
A certificate is just a signed wrapper for a key, with
A couple slight clarifications/corrections:
... IF AND ONLY IF you have the original private key. (Because the
public key is stored with it in the same file).
certificates signed with the private key that corresponds to the
public key they wrap
On Feb 24, 5:18 am, Bob Kerns r...@acm.org wrote
One other small point -- in theory, if you got every detail exactly
right, you could even reproduce your original certificate, so long as
you still have that original private key.
Or you could recover the certificate from a copy of the product.
It's the private key you have to guard with your
Thanks for the pointer, Jens -- this looks like a nice option.
Slow-and-robust is probably the most useful addition to the
repertoire, and having a standard interface is a big plus!
On Feb 24, 12:23 am, Jens dunkingbikk...@gmail.com wrote:
Tagsoup. You can add the lib to your project or (ab)use
For what it's worth, this isn't an Android-specific issue.
I remember grumbling about my down-rev version of Windows Mobile and
waiting for HTC to get an update out to me. I never did get it.
While the iPhone does have the issue to a slight degree, Apple's
tighter control of the platform raises
Well, you're running Java 1.5, and he said his works in 1.5 but not in
1.6, so it doesn't seem to be quite identical.
Your stacktrace looks like you may have a font installed with
corrupted metrics.
You could try using a newer version of Java, or you could try removing
any non-standard fonts
I really doubt that Eclipse is wrong here. First, a couple quick-and-
basic steps.
If you hold the mouse over each variable, it will tell you the type.
Finally, if you click on the 'this' the code, and type control-T,
you'll get a pop-up with showing the class hierarchy. The second from
the type
Perhaps you should consider that the people who came up with Android's
convention had a lot more Java experience under their belt than the
people who came up with Java's convention had, way back when.
I'm not saying that makes the case, just that your argument-from-
authority here falls flat.
A wild thought: I'm wondering if you pass the same == Runnable in to
postDelayed() if the second call perhaps actually resets the earlier
one to a new time?
It's not documented to do that, but it would fit your observed
behavior.
Instead of mWaitRunnable, try passing new Runnable() { ...}
.
On Feb 23, 2:20 pm, Bob Kerns r...@acm.org wrote:
A wild thought: I'm wondering if you pass the same == Runnable in to
postDelayed() if the second call perhaps actually resets the earlier
one to a new time?
It's not documented to do that, but it would fit your observed
behavior.
Instead
Very clever!
If Eclipse handles that gracefully, it looks like a very good
solution.
Even if Eclipse doesn't handle dropping in a physical file gracefully,
you just have to turn off the link manually, or live without the
ability to override locally.
The only downside is having to explain what's
This is seriously easy to do, and nobody needs to get hurt if you're
careful about what port you use, are willing to try a few
alternatives, and shut it down when you're done.
You don't even have to implement HTTP -- all you have to do is LISTEN,
ACCEPT, read the request a line at a time up to
I like that document, but I'd add a caveat: don't go all gung-ho style
police. (I think that fits well with the overall tenor of the
document, but is worth being made explicit).
The point of style conventions is to make things easier, not provoke
arguments.
There is, in fact, some benefit from a
Yes, it's OK in Java to extend SecureClassLoader, but I don't think
it's going to help you, unless there's a whole lot of magic I don't
know about.
The dalvik VM doesn't use Java's standard byte codes. You'd have to
post-process them into the stack machine format it does use.
I have no idea how
I think you're looking for these:
android.intent.action.ACTION_POWER_CONNECTED
android.intent.action.ACTION_POWER_DISCONNECTED
I located them looking through platforms/android-2.1/data/
broadcast_actions.txt, which is a WHOLE LOT EASIER than looking in the
documentation, where this is scattered
You have NO IDEA what a can of worms this is!
The problem is, real-world HTML is simply NOT STANDARD. That is,
there's a standard, it's kind of loose, and people violate it all the
time. Browsers understand this, and have VERY forgiving parsers.
But a good forgiving parser is a lot harder to
I should add that one reason you may not have been able to understand
some of the HTML parsers you've seen, is that a lot of them are
written by so-called compiler compilers, better described as parser
generators, based on a specialized parsing language. The output is
not really human-readable, to
Yeah, google-fu fails when you are the first to try something -- or
when those who have gone before are too foolish to ask their question
in public!
This way you get to both pose the question and the answer for the next
person to try this.
Anyway, the first thing I'd do is to think long and hard
. I should
probably direct my complaint elsewhere, where it might reach the
people responsible for the documentation.
On Feb 22, 4:46 am, Mark Murphy mmur...@commonsware.com wrote:
Bob Kerns wrote:
I located them looking through platforms/android-2.1/data/
broadcast_actions.txt, which
I'm not fond of 'this.member'. It seems to combine the worst of both
worlds -- an optional prefix that may or may not be used in different
places.
Though I understand why people use it in setters and constructors to
avoid manging their argument names -- real prefixes avoid that need.
On Feb 22,
The aapt command has a -c option which governs which configurations to
include (default = everything). Since the Gallery comes with specific
devices, it wouldn't surprise me if it's configured to only include
assets targeting a specific platform.
Check your default.properties file for
I haven't read the code (not even the Java side). I can only guess
that in streaming mode it allocates a buffer it manages as a ring
buffer, or something like that.
But I'd expect that to only happen at startup. Any delays in write()
calls I'd expect to be simply waiting for room to copy the
Was it actually your app that was getting the error?
The Launcher suffered from this problem in 2.1 on a Nexus One if you
had a lot of applications; it seems fixed in 2.1 Update 1.
If it's your app, you can investigate this from the DDMS perspective.
Select your app, hit the Update Heap button
I think his use of the main Looper is OK -- though not something I
would endorse, in part, because:
I think the problem is in the lifetime of his handlers.
Yidongsoft:
Normally, you allocate the Handler in your main thread -- and then
HANG ONTO THEM, generally in an instance field of your
Google Marketplace only accepts Google Checkout, so if you're selling
through Google Marketplace, you can't use PayPal either directly or
indirectly (it's in your agreement).
If you're selling from your website, or from one of the other Android
stores, you'll have to deal with PayPal's own set of
at 7:15 PM, Bob Kerns r...@acm.org wrote:
But aside from that, my experience is that the code based on the
blocking API will be simpler and have many fewer bugs, and roughly the
same performance characteristics if done right. (But as I mentioned
earlier, the need for threads means
...@commonsware.com wrote:
Bob Kerns wrote:
* Create your Handler in the context of whatever you want to associate
with handling it. For example, if you're updating a view in an
activity, create it in the onCreate() method for the view.
* Save your handler in an instance variable in that context
If you're using a WebView, the answer is yes.
WebView webview = ...;
WebSettings settings = webview.getSettings();
String uastring = settings.getUserAgentString();
I don't know of a way to ask the Browser application itself -- but if
you're doing this level of stuff, you may be wanting more
中村さん、
TextView's setText method is declared to take a CharSequence, rather
than simply a String. This (and many other places) do so, to allow you
to use other types besides String.
Specifically, SpannableString, which is like a String, but allows you
to attach additional information, such as
When you stream buffered data, you have a minimum of two buffers -- at
least conceptually. (You can implement it somewhat differently, but it
boils down to the same thing the way I look at it).
You fill up one buffer, and give it off to the system or the hardware
or another thread. While it is
of the code.
On Wed, Feb 17, 2010 at 7:27 PM, Bob Kerns r...@acm.org wrote:
The 70 ms here isn't due to the blocking nature, but due to the buffer
size. With a 2.5 ms buffer size, you'd be able to stop the sound in
5ms even when both buffers were full. It really has nothing to do
Yes, that's a completely different question than getting data from res/
values/strings.xml -- even though they look like the same thing!
It's also an easy question you would have answered yourself, were you
not expecting there to be an event! A reasonable idea, but incorrect,
and that's what's
The 24h trial isn't so much for trial usage as it is to give people
courage to make that download, knowing that they might not like it
once they get to see it, or it might not even work.
And at the typical price point, you do NOT want to have to support
customers who aren't happy (and won't be
We shouldn't even be calling a 24h trial. Google doesn't call it that,
and it's NOT that. It's a 24h refund policy. It's a buyer security
policy, and NOT A TRIAL POLICY.
We have to nip that meme in the bud. It's a bad way to think of it for
both developers AND for users.
If you want a 24-hour
Using a custom ArrayAdapter doesn't seem to me to relate to your
question, unless your problem is that it's broken. For example, if
yours doesn't notify the registered DataSetObservers that the data has
changed.
As for async tasks -- what you're describing IS a one-shot task, in
any sense that
The 70 ms here isn't due to the blocking nature, but due to the buffer
size. With a 2.5 ms buffer size, you'd be able to stop the sound in
5ms even when both buffers were full. It really has nothing to do with
blocking/non-blocking, which simply has to do with who has to do the
blocking and
You've been ably answered, and solved your problem, but I notice that
nobody ever explained WHY your progress bar didn't show up.
You may have inferred the answer yourself, but I'll state it
explicitly: You never gave it a chance to, because the thread that
would have displayed it -- the main UI
There are two approaches to handling this, depending on what you want
to accomplish.
There's a per-Activity flag in the manifest:
android:finishOnTaskLaunch=true. Use this on individual activities
which should disappear, because they are ephemeral by nature.
If the overall nature of the
I think you'll need to supply the android:layout attribute, and supply
an alternative layout with the background set.
You can find the default layout in the SDK at platforms/android-2.1/
data/res/layout/preference.xml
If you just want to customize the widget portion, use
android:widgetLayout
Delegation is more powerful than inheritance, even multiple
inheritance. (But multiple inheritance can often express the same
ideas more concisely, declaratively, and consistently).
The simplest thing to do is to delegate to methods your Application
object for creating and preparing the menus.
From your description, it sounds like everything is happening just as
designed, and as it should, and that the only problem is that you feel
your program isn't complicated enough.
Is that a fair assessment? You get the right result. Your code spends
most of its time waiting for the hardware,
701 - 800 of 886 matches
Mail list logo
