backwards-compatibility

Android: how to the design app for Smartphone AND Tablet?

只愿长相守 提交于 2019-12-06 12:29:57
I know there are already quite a lot of blog entries , how to's , questions out there that cover backward compatibility of Android 3.0 apps. However, after reading them all I'm just more confused than before. :( What I have is a Smartphone app that supports min. SDK version 8 (2.2). I now want this one to stay the same on Smartphones, but also provide a fancy version on Honeycomb Tablets with Action Bar and Fragments and so on. I know there is the compatibility pack, but all I read about it was about Fragments. What's with the Action Bar and the holographic Theme? I did get this pretty nice

Java JDK 11 Breaking Old Jars/Programs

不羁的心 提交于 2019-12-06 10:37:06
It is to my understanding that Java JREs are backwards compatible, if you write a program in Java (JDK) 7, it will run with Java (JRE) 8. I have a couple of programs I developed in Java 8, and have .jar and EXE files that I built when I finished them, and they always ran fine. However, after installing Java JDK 11 (11.0.2), these old .jar files break... A couple of them still run, but their GUIs have expanded, with buttons and images being bigger than before, and in some cases blurry One program just doesn't run at all, trying to run it in a console gives an exception: " Exception in thread

Upgrade Jackrabbit 1.3 to Jackrabbit 2.1.1

廉价感情. 提交于 2019-12-06 08:09:19
In my project I need to change Jackrabbit 1.3 to Jackrabbit 2.1.1. My work is to work for queries. Please suggest me if there are changes in index format and query format. Lucene 2.4 is used in Jackrabbit 2.1.1 while in Jackrabbit 1.3 Lucene 2.2 is used. Lets divide your upgrade into the following parts: Upgrade 1.3 to 1.5 (see Class IndexMigration ): IndexMigration implements a utility that migrates a Jackrabbit 1.4.x index to version 1.5. Until version 1.4.x, indexes used the character '' to separate the name of a property from the value. As of Lucene 2.3 this does not work anymore. See

Protobuf backward compatibility and proto3 vs proto2

给你一囗甜甜゛ 提交于 2019-12-06 07:49:56
One of selling points of Protobuf was backward compatibility, i.e. developers can evolve format, and older clients can still use it. Now with new Protobuf version called proto3, the IDL language itself is not compatible as such things as options , required where dropped, new syntax for enuns, no extention. Does it mean that using proto3 there's no way to produce binary that older proto2 would read/understand also? It is like you have to continue to use proto2. If you start using proto3, you can't talk to older systems, or have to rewrite, recompile all those .proto s That is compatibility

semantic versioning of API bundle

一曲冷凌霜 提交于 2019-12-06 07:44:53
When starting with a package versioned at 1.0.0 in an API bundle, what should the new version be after adding a new interface to said package? The whitepaper makes this statement regarding compatibility: It should be obvious that binary compatibility plays an important role in backward compatibility. However, backward compatibility is also very dependent on the semantics. If the responsibility of an interface changes it could still be binary compatible but no longer be backward compatible. At the same time... 3.micro — A difference in the micro part does not signal any backward compatibility

Extend an existing API: Use default argument or wrapper function?

徘徊边缘 提交于 2019-12-06 06:04:17
I have an existing method (or function in general) which I need to grow additional functionality, but I don't want to break any use of the method elsewhere in the code. Example: int foo::bar(int x) { // a whole lot of code here return 2 * x + 4; } is widely used in the codebase. Now I need to make the 4 into a parameter, but any code that already calls foo::bar should still receive what it expects. Should I extend and rename the old method and wrap it into a new one like int foo::extended_bar(int x, int y) { // ... return 2 * x + y; } int foo::bar(int x) { return extended_bar(x,4); } or should

How to create a new Xcode 5 project that is backwards compatible with iOS 5.0? - Getting missing Storyboard error

一世执手 提交于 2019-12-06 05:41:55
Our client requires an iPad/iPhone app that covers iOS 5.0 - iOS 7.0. I created a new project in Xcode 5 In build settings I changed the architecture to standard Standard armv7 , armv7s I clicked on the Main.storyboard and made sure that the interface builder settings were: Opens in: Default (5.0) Builds for: iOS 5 and Later View as: iOS 6.1 and Earlier In Deployment Info I changed the Deployment Target to 5.0 I can see my old simulators now, but running an empty single application project in iOS 5.0 simulator gives me this missing storyboard errors that many have reported: Terminating app due

Android: How to maintain backwards-compatibility?

不羁的心 提交于 2019-12-06 05:15:59
According to the instructions found here , to make your app state which screen sizes you can support, you'll need to compile your app against Android 1.6. Using the minSdkVersion and targetSdkVersion this should run also on Android 1.5: <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"/> However, when I try to launch my app from Eclipse to run in a emulated 1.5, I get the following error: Failed to find an AVD compatible with target 'Android 1.6'. Is this an error of the eclipse tools/emulator? Or how do I get it to also target 1.5 correctly while giving me the option to specify

How to make sure ES3 programs will run in an ES5 engine?

旧时模样 提交于 2019-12-06 03:56:13
问题 So ECMAScript 5 introduces some incompatibilities with ECMAScript 3. Example : Many articles have been written stating that this === null || this === undefined is possible in ES5 strict mode : "use strict"; (function () { alert(this); // null }).call(null); But, what the standard really suggests is that ES5 engines also allow this in non-strict mode : 15.3.4.3 ... The thisArg value is passed without modification as the this value. This is a change from Edition 3, where a undefined or null

Spring 4.0.0 backward compatibility

隐身守侯 提交于 2019-12-06 03:20:49
I've searched and couldn't find anything to suggest that Spring 4.0.0 is not fully backward compatible with Spring 3.x. Is that indeed the case? There are few API they have removed in the new version. You would not have any surprise changes with the new version, there could be slight changes in the API. But, you have to watch the deprecated APIs which will be the candidate for removal in the forthcoming versions. Look at this document , they have included few backward compatibility changes and removal of the APIs. The backward compatibility for object-mapper option of the and components has