> Public bookmarks 01/17/2014 (a.m.)
Public bookmarks 01/17/2014 (a.m.)
IntelliJ IDEA and Android Studio FAQ | JetBrains IntelliJ IDEA Blog
If I’m already a user of IntelliJ IDEA, do I need to switch to Android Studio for Android development?
No. Android Studio is focused specifically on Android development and provides streamlined environment and project setup, but otherwise all of its features are available in IntelliJ IDEA.
IntelliJ IDEA Community Edition is completely free and open-source, licensed under the Apache 2 license and can be used for any kind of development. Android Studio has the same licensing terms.
Unchecked Exceptions — The Controversy (The Java™ Tutorials > Essential Classes > Exceptions)
One case where it is common practice to throw a
RuntimeException is when the user calls a method incorrectly. For example, a method can check if one of its arguments is incorrectly
null. If an argument is
null, the method might throw a
NullPointerException, which is an unchecked exception.
How to Design a good API and Why it Matters
Java API Design Guidelines
The best approach is to say that once something is in the API it will stay there
and it will continue to work. Tweaking the API incompatibly between revisions will result in user reactions ranging from annoyance to murderous rage. The problem is particularly severe if your API ends up being used by different modules that are part of the same application. If Module 1 uses Commons Banana 1.0 and Module 2 uses Commons Banana 2.0 then life will be a whole lot easier if 2.0 is completely compatible with 1.0. Otherwise your users risk wasting huge amounts of time tweaking classpaths in a futile endeavour to make things work. They might end up having to play mind-destroying games with class-loaders
, which is a clear signal that you have failed.
Because of the compatibility requirement, it’s much easier to put things in than to take them out. So don’t add anything to the API that you’re not sure you need.
There’s an approach to API design which you see depressingly often. Think of everything a user could possibly want to do with the API and add a method for it. Toss in protected methods so users can subclass to tweak every aspect of your implementation. Why is this bad?
The more stuff there is in the API, the harder it is to learn. Which classes and methods are the important ones? Which of the five different ways to do what I need is the best?
The situation is exacerbated by the Javadoc tool, which dumps all the classes in a package, and all the methods in a class, in an undifferentiated lump. We can expect that JSR 260 will update the Javadoc tool to allow you to produce “views” of the API, and in that case fatter APIs will not be so overwhelming.
The bigger the API, the more things can go wrong. The implementation isn’t going to be perfect, but the same investment in coding and testing will yield better results for a smaller API.
If your API has more methods than it needs, then it’s taking up more space than it needs.
The right approach is to base the API on example code. Think of problems a user might want to solve with the API. Add just enough classes and methods to solve those problems. Code the solutions. Remove anything from the API that your examples don’t need. This allows you to check that the API is useful. As a happy side-effect, it gives you some basic tests. And you can (and should) share the examples with your users.
Callbacks. If the interface is intended to be implemented by user code, then it is often more appropriate than an abstract class.
The Java language has fairly limited ways of controlling the visibility of classes and methods. In particular, if a class or method is visible outside its package, then it is visible to all code in all packages. This means that if you define your API in several packages, you have to be careful to avoid being forced to make things public just so that code in other packages in the API can access them.
The simplest solution to avoid this is to put your whole API in one package. For an API with fewer than about 30 public classes this is usually the best approach.
A good convention for private packages is to put
internal in the name. So the Banana API might have public packages
com.example.banana.peel plus private packages
Posted from Diigo. The rest of my favorite links are here.